This post is intended for developers who are learning about testing their code. The goal of this post is to share a concise, plain-language explanation of snapshot testing.
What is a snapshot test?
A snapshot test is a specific kind of technique for regression testing, that is, tests that make sure changes to a code-base do not cause other existing functionality to break. In snapshot testing, the output of a function is saved in a file (the “snapshot”), and when the test runs, it compares this saved output with the output of the function when it is run each time in the test suite.
For example, let’s say there is a PHP or JavaScript function, greeting() , that should output <h1>hello</h1> every time it runs. This markup string would be stored in a file, for example, tests/snapshots/greeting.html. A system within the test suite should be in place to make sure the output of greeting() is equivalent to the contents of the file with the same name. In the future, if we refactor code to change how the markup is generated, for example, this snapshot test will check that the function is still outputting what we expect.
The potentially tricky part about snapshot tests is that they will fail even when the output is intentionally updated. For example, if we decide to use an h2 in the output or if we decide to add a class to the h1 , our snapshot test will fail. Because of this, snapshot tests need to be updated when a change is made to the output. Sometimes this can be cumbersome, but the value of regression testing generally makes up for this additional work.
In the wild
Snapshot testing is a common practice in the JavaScript ecosystem, for example, to check that a React component outputs the correct JSX or HTML given certain conditions. Creating the support for snapshot testing requires some initial setup, and it’s common to use a third-party tool, such as Jest, to provide this setup.
One example from the Gutenberg codebase is where a test calls a component, ColorPaletteControl, and compares the result to output stored in a file. Here is the directory where this happens. See if you can find 1) where the component is called in a test, and 2) where the output is stored in a snapshot file.
I wrote the “What is a snapshot test?” section here for documentation at my job. Initially, I wrote a whole list of steps to create and update snapshot tests within our system, but all of that assumed some critical prior knowledge. My coworker pointed this out to me, and asked, “What is a snapshot test?” I am very grateful that she asked because 1) our documentation is much better, and 2) I have some content for a blog post 😎.