Book 10 · Testing & QualityPage 25 of 36

Snapshot Testing

In Turkish: Snapshot Testi

Updated September 30, 20262 min read

In short

Snapshot testing is a technique that saves the output of code to a file on the first run and fails later runs if the output no longer matches that copy.

What is snapshot testing?

Snapshot testing checks that some output, such as rendered HTML, a UI component, a JSON response, or a command-line message, hasn't changed unexpectedly. The first time the test runs, it records the output in a snapshot file that is committed to the repository. Each later run produces the output again and compares it with the saved snapshot, and any difference makes the test fail.

When a snapshot test fails, a developer reviews the difference, called a diff. If the change is a bug, they fix the code; if the change was intentional, they update the snapshot, usually with a single command, and commit the new version so reviewers can see exactly what changed. In many JavaScript test runners, this is a single assertion such as toMatchSnapshot(), and some can store small snapshots inline in the test file itself.

It's like taking a photo of a finished room so you can later spot anything that has moved. Snapshot tests are popular for frontend UI components, where writing an assertion for every element would be tedious. They also suit serializers, compilers, code generators, and API responses, where the output is large but should stay stable.

Snapshot testing is not the same as visual regression testing, which compares real screenshots pixel by pixel; a typical snapshot stores a text representation, such as serialized markup. The main pitfall is blind updating: if snapshots are huge or change often, developers start accepting every diff without reading it, and the tests stop catching bugs. Values that change on every run, such as timestamps or random IDs, must be replaced with fixed ones, or the snapshot will never match.

Key takeaways

A snapshot test compares the current output with a saved, committed copy.
The first run creates the snapshot; later runs fail if the output differs.
Intentional changes are accepted by updating the snapshot and committing it.
It suits large, stable outputs such as UI markup, serialized data, and generated code.
Large or frequently changing snapshots lead to blind updates and weak tests.

Example

A snapshot test with the Node.js built-in test runnerjavascript

import { test } from "node:test";

function renderBadge(user) {
  return '<span class="badge">' + user.name + " (" + user.role + ")</span>";
}

test("renders a user badge", (t) => {
  // Run once with: node --test --test-update-snapshots
  // That saves the output to a snapshot file; later runs fail if it changes.
  t.assert.snapshot(renderBadge({ name: "Ada", role: "admin" }));
});

Readers ask

When should you update a snapshot?

Only after you have read the diff and confirmed that the new output is the intended result of your change. If you can't explain why a snapshot changed, treat the failure as a possible bug.

What is the difference between snapshot testing and visual regression testing?

Snapshot testing usually compares a text version of the output, such as serialized HTML or JSON. Visual regression testing captures real screenshots in a browser and compares them pixel by pixel, which catches styling problems that text snapshots miss.

Should snapshot files be committed to version control?

Yes. Snapshots are the expected results of your tests, so they belong in the repository and should be reviewed in pull requests like any other change.