Snapshot testing promises a shortcut: write a test once, capture the output, and let the framework flag any deviation from that moment forward. It sounds rigorous. In practice, snapshot testing is one of the most widely misused techniques in modern front-end development, and Australian dev teams adopting it without understanding its limits are building a test suite that looks healthy and behaves otherwise.
The core mechanic is simple. A snapshot test renders a component (or serialises any value, really), stores the result to a file, and then on every subsequent run it checks whether the output matches. Jest, which handles most of the snapshot testing workload in JavaScript projects, makes this two lines of code. That accessibility is part of the problem.
What snapshot testing actually catches
Snapshots are genuinely useful for one class of problem: unintended structural regressions. If a developer refactors a shared component and accidentally drops an attribute, reorders a list, or changes a class name that downstream CSS depends on, a snapshot test will catch it. That's real value. No argument there.
They also work well for serialised outputs that change rarely and matter a lot. Serialised API response shapes, configuration file structures, and CLI help text are reasonable candidates. The common thread is that the output is stable by design, changes are intentional and infrequent, and a deviation is almost always a bug rather than a feature.
Snapshot tests are fast to write and fast to run. For teams with no coverage at all on a legacy UI layer, even shallow snapshots buy some regression protection during a refactor. That protection is worth something, even if it's not the whole story.
What snapshot testing misses
Here's the failure mode that bites teams hardest: snapshots don't assert intent, they assert output. A snapshot tells you the component rendered this HTML. It doesn't tell you the HTML was correct, or that the button triggers the right action, or that the form validates properly, or that an error state is handled.
Worse, snapshots become noise fast. The first time a team runs jest --updateSnapshot to clear out a batch of failures after a design system update, the habit is formed. Updating snapshots stops feeling like a decision and starts feeling like a chore. Within a few months, developers are bulk-accepting snapshot changes they haven't read. The test suite still reports green. The regressions still ship.
This connects directly to the problem that mutation testing exposes in test suites that look healthy on coverage metrics: passing tests and useful tests are not the same thing. A snapshot test that gets updated without review is a test that no longer tests anything.
Large snapshots are an especially common trap. A snapshot of an entire page component can run to hundreds of lines of serialised HTML. Nobody reads those diffs. Nobody. The test still runs, the file still exists, and the team still counts it as coverage. Three things that give the appearance of quality control without providing it.
When to use snapshot testing and when not to
The useful heuristic is this: if the thing being snapshotted changes for reasons outside the developer's control (a parent component update, a data-driven render, a library upgrade), snapshot tests will generate regular noise. Noise leads to bulk updates. Bulk updates lead to ignored tests. Don't snapshot those.
Do snapshot things that are deliberately stable: design tokens, icon sets rendered to SVG, the shape of a serialised data structure, the output of a code generator. These are outputs where any deviation, however small, is a genuine signal worth investigating.
For component behaviour, prefer explicit assertions. Does the button render with the right label? Check the label text directly. Does the modal close on escape? Simulate the key event. Does an error state display the right message? Assert the message text. These tests are slightly more work to write and far more resilient to incidental change.
The teams that get the most from snapshot testing treat it as a complement to behaviour-driven tests, not a substitute. Snapshot coverage of a component's rendered output, combined with event-driven tests for its interactions, gives you both regression detection and intent verification. Either one alone is insufficient.
Keeping snapshot files under control
Snapshot files belong in version control. That's non-negotiable. A snapshot that isn't committed is a test that disappears on a fresh checkout, which defeats the entire purpose.
But snapshot files accumulate. Components get deleted or renamed, and their snapshot files stick around unless someone cleans them up deliberately. Jest's --ci flag helps here: it fails the run when a snapshot is missing rather than silently creating one, which forces the issue into the open during CI.
Review snapshot diffs as carefully as you review code diffs. This is the discipline most teams let slip first. A PR that modifies 400 lines of snapshot output deserves the same scrutiny as a PR that modifies 400 lines of application code. If the diff is too large to read meaningfully, the snapshot is too large. Break it down or replace it with targeted assertions.
For teams thinking about pipeline quality more broadly, the principles that apply to contract testing for service boundaries apply here too: a test is only as useful as the signal it sends when it fails. If a failure prompts an automatic update rather than an investigation, that test has stopped working.
Inline snapshots as a middle path
Jest supports inline snapshots, where the serialised output is stored directly in the test file rather than a separate __snapshots__ directory. For small, stable outputs, this is a better pattern. The snapshot lives next to the code that generated it, the diff is visible in the same file as the test logic, and reviewers are far more likely to actually read it.
Inline snapshots don't scale to large outputs. But for a 10-line serialisation of a configuration object or a small presentational component, they're worth the switch. The review discipline improves almost automatically.
Snapshot testing is a tool, not a strategy. Australian dev teams that understand its constraints will use it to catch a narrow but real class of regressions. Those that treat it as a coverage shortcut will eventually discover that their snapshots are testing nothing except their own tolerance for green builds.