Jest — Snapshot Testing

Today I would like to give you a small overview of what can and what can not be done with the new and shiny snapshot testing feature of Jest. Maybe it will help you to decide if Jest is the right tool for you to test your application or if other ones would work better for you.

What is snapshot testing?

The idea is quite similar to the UI snapshot tests some of you may know: You take an image of your current app in a specified state and compare it to the previous image you have taken. The problem if you use actual images is that they are big, contain a lot of unused information, depend on your (maybe changing) environment (e.g. browser size). Because of these problems, they feel heavy, the tests take a time to complete and may occasionally fail for no reason. The way Jest improves this situation is that it uses a test renderer to render your React or React Native components to a JSON representation. This representation is stored with the new snapshot feature and may be diffed against new test runs results.

Let’s have a look at the code

So if you would like to write a test for a component in a given state you may write a test like this one:

This will generate this snapshot in a nested folder, which you should commit along with your code:

As you see, the format is completely human readable, and you may simply change it to specify other behavior by yourself.
If you would like to see these tests in action, here is my evaluation repository for jest.
So now that you know how a test with the new snapshot feature may look like let’s talk about the pros and cons of using it.

Pros

For me, the biggest advantage is the simplicity in which you may write tests. For example, if you have very simple UI component, like a button or headline, and you would like to ensure it behaves as it should I am often not sure if I should write tests or not. The functionality may be too easy to test it, writing more testing code and boilerplate may seem to be a bit of overhead. But often as the component grows it gains complexity, and you may forget to write tests, opposed to if there were already tests you would simply enhance them.
If I got to write tests this easily, just writing some as I am building my component wouldn’t be an effort at all.

Cons

To my mind, the biggest problem is that you don’t specify directly which parts of the snapshots are the ones you would like to test. For example, if I have a button component, and I choose to move it from an a-tag to a button-tag the test will fail, although it may be totally fine. You don’t specify the level of abstraction you would like to have tested, but you test on the most detailed one.
Another problem from my point of view is that I can’t do classic TDD, as I would have to write a snapshot on my own, which is probably not a thing I would be willing to do.
And last but not least, currently there is a problem with the dependencies, you don’t get to install React, React Native, test-renderer and jest without at least one unmet dependency error.

Conclusion

My conclusion is that jest (if the dependencies are fixed) may be used as one part of your toolset for testing small UI components. If I am completely honest, my favorite approach would be to separate the snapshot feature from Jest and use it in any other test setting to reduce the tooling overhead.

Want to hear more from me? Feel free to subscribe to my newsletter; I send out news roughly once a month.