Setting Up a Snapshot Testing Strategy for Components

1. The basic principle of snapshot tests

A snapshot test renders a component once, serializes the result (typically as an HTML or JSX structure) into a readable text file, and stores it as a reference snapshot in the repository. On every subsequent test run, the component gets rendered again and the result gets compared character by character against the stored snapshot, where any deviation at all, from a changed CSS class to a new wrapper element, fails the test.

This mechanism makes snapshot tests extremely easy to create, since no developer has to formulate explicit assertions about the expected content, only mark the current state as "correct", which at first glance looks like an enormous time saving compared to traditional, hand-written assertions.

2. The central problem: reflexive snapshot acceptance

The decisive, regularly underestimated weak point of snapshot tests in practice is that a failed snapshot test says nothing about whether the change is actually correct or a bug, only that something changed. Under time pressure, say shortly before a deployment, developers tend to run the command to update all failed snapshots wholesale, without actually reading and substantively assessing every single diff.

This behavior causes snapshot tests to gradually lose their entire protective effect: an actual bug showing up as an unwanted change in the rendered output gets reflexively accepted the same way as an intentional, harmless change, letting the test stay formally green even though it has completely failed its actual job of catching unintended changes. What makes this especially insidious is that this gradual loss of meaning stays unnoticed by the team for a long time, since the test suite keeps passing formally and completely, conveying a deceptive sense of safety that only gets exposed once a bug the snapshot test could theoretically have caught actually surfaces in production.

3. Full snapshots vs. targeted, minimal snapshots

A full snapshot of the entire rendered component, including all nested child components and their HTML structure, reacts to practically any change anywhere in the component hierarchy, even to completely unintended, irrelevant side effects of a change in a totally different, shared child component, unnecessarily inflating the number of snapshot changes that need review but are actually irrelevant.

A targeted, minimal snapshot instead deliberately limits itself to the properties actually relevant to the given test, say only a specific element's computed CSS classes or only a formatting function's textual output, instead of capturing the entire DOM structure. This deliberate approach requires somewhat more initial thought when writing the test, but considerably reduces the number of irrelevant, distracting diffs on later changes.

// TARGETED: only the computed CSS classes, not the entire DOM structure
test('price display gets discounted class on a discount', () => {
  const { getByTestId } = render(<PriceDisplay price={80} originalPrice={100} />);
  expect(getByTestId('price').className).toMatchSnapshot();
});

// AVOID: a full snapshot of the entire component
test('price display snapshot', () => {
  const { container } = render(<PriceDisplay price={80} originalPrice={100} />);
  expect(container).toMatchSnapshot(); // reacts to ANY change in the tree

4. Review discipline: actually reading snapshot diffs in the pull request

Since automated tools can't substantively judge a snapshot diff, a functioning snapshot testing regime needs explicit review discipline: every change to a snapshot file within a pull request should be read just as carefully during code review as a change to the actual production logic, not overlooked as a mere formality.

A helpful, organizational trick is to explicitly mark snapshot files in the pull request view as "deserving special scrutiny", say via a CODEOWNERS rule that automatically triggers an additional, targeted reviewer assignment for changes to `.snap` files, instead of letting them get lost in the general diff noise of a large pull request.

5. When snapshot tests are actually worthwhile

Snapshot tests deliver their greatest benefit for stable, rarely changed components with complex but predictable output, say a function that generates a formatted currency display from structured pricing data, where an unintended change to the formatting logic should immediately and reliably stand out, without having to formulate an explicit, hand-written assertion for every possible input combination.

Snapshot tests are also well suited for serializing complex data structures, say the output of an API response transformer, where a textual diff representation is grasped faster than a long chain of individual, explicit property assertions.

6. When snapshot tests should rather be avoided

For components changed frequently and deliberately, say during an active UI redesign, full snapshot tests generate a flood of irrelevant but formally failing tests on practically every small design tweak, which actively fuels the reflexive acceptance habit from the previous section, since developers under this load rarely find the time to carefully review every single change.

Snapshot tests are also unsuited for components with time- or randomness-dependent content, say a relative timestamp like "3 minutes ago", since the snapshot inevitably deviates at every different point in time the test runs, unless the corresponding values get explicitly and reliably frozen for the test.

7. Distinguishing it from visual regression testing

Snapshot tests in the sense described here compare a component's serialized code or DOM structure, while visual regression testing (see the separate article on this topic) compares actual pixel screenshots, meaning both test types cover different, complementary error classes: a snapshot test catches a changed CSS class in the structure, while a visual regression test rather catches when the same CSS class now looks different due to a changed, global stylesheet rule, even though the structure stayed unchanged.

A well-thought-out test portfolio deliberately combines both approaches: snapshot tests for the structural correctness of individual components at the unit/component test level, visual regression testing for the actual, visual appearance of critical pages at the E2E level.

8. Detecting and regularly cleaning up outdated snapshots

Over time, a grown project frequently accumulates orphaned snapshot files whose associated component or test case has long since been deleted or renamed, without the corresponding snapshot file ever being removed alongside it, letting the snapshot directory grow uncontrollably over months and become increasingly hard to survey. Most snapshot testing tools offer an explicit command to automatically find and remove exactly such orphaned, no-longer-referenced snapshots, which should be run regularly, say once a quarter, as its own small maintenance step.

A well-maintained, tidy snapshot directory not only makes navigating the code easier, but also reduces cognitive load during code review, since reviewers no longer have to distinguish between actually relevant and long-since-irrelevant, orphaned snapshot changes.

9. Snapshot strategies at a glance

The table below summarizes the snapshot testing strategies presented.

10. Summary

11. FAQ: Snapshot Testing: The Essentials at a Glance