09. April 2021
timer-icon 4 min

When Snapshot Testing will make you snap

Frontend Code validated by snapshot testing

In modern frontend development, there is a rise of component based frameworks and libraries such as React and Angular. And with them came new ways of testing Web-UI-Code. The most well known example is snapshot testing. It grew within the React community and offers a lot of benefits.

However, today we want to focus on the things that can go wrong. So let us first have a brief look at what the method is. Afterwards we will see how it could undermine your testing efforts.

What is snapshot testing

Snapshot testing is a term used to describe approval testing for the frontend community. Or is it the other way round? Anyways: The basic idea is to take pieces of plain text and compare them to a stored baseline.

Frontend developers love this technique. And for good reason. With little to no effort, we can write tests, that do a multitude of things in regards to verifying our DOM and data structures. A snapshot test could look like this, with the resulting snapshot below.

One thing stands out: very little lines of test code validate both, our CSS and HTML code. That looks awesome and saves time. But be aware of the hidden traps.

Snapshot Testing can break your teams discipline

What happens a lot, when developers get excited for snapshot testing is clear. They over use it. But how can this happen? The answer is simple. Lets asume you have a component or page like the following and use a snapshot test to verify it.

As you might assume, the used components have some code on their own. A snapshot of this will result in a wall of text. This leads to three main problems. First, the test will fail with every change in our application. Second, it will never fail alone, since we hopefully test our components as well. And third: think about a project deadline. Would you really read the following snapshot?

Did you notice the buttons color? I didn’t. Most developers I know would be confident enough to trust their capabilities. They would enter jest -u and “solve” the problem at hand. And thats not even 200 lines for our small sample application. Imagine real world pages or templates, rendering up to thousands of lines.

While the first two points are just annoying, but not a big deal, the last is bad enough to cause serious headaches. At this point, the usefulness of your snapshot tests relies completely on the discipline of your team! As did the value of all of your tests, since those snapshots make it hard to find real problems. And it will happen, that someone updates the snapshots without even realizing, that there is a problem within another component.

Is Snapshot Testing bad?

No! Snapshot Testing is awesome. I love it. The moment i discovered it, I started to save insane amounts of time. All I am saying is: Use the right tool for the job. If you combine multiple small or medium sized components to a template or a page, snapshot testing is often the wrong choice. You could either use visual regression for that purpose or just check if all your components are displayed individually.

Are you looking at a small component, leading to a snapshot with less than 100 lines? Use it. It is awesome! And never forget: It is more than just a tool for validating DOM integrity. Do you have an algorithm producing data structures? Snapshot testing can be useful as well. But always remember: If you can not read the snapshot within half a minute, consider using something else.

Some final words

Personally, I am done talking about snapshot testing for today. But if you want to learn more about testing for your Frontend Code, stay with us. We will cover several other topics in the near future. And one important thing before I am done: leave a comment. I’d love to learn from your experience!

Comment article