Snapshot Testing Is Just JSON Diffing With Extra Steps — Here's Why That Explains Both Its Strengths and Its Noise

Snapshot testing — a popular technique in modern test suites — is, underneath, just "save a JSON diff result and fail the test if it's not empty next time" — and understanding it this way explains both why snapshot tests catch real bugs and why they're notorious for generating noisy, rubber-stamped diffs

The previous articles on this site covered structural diff fundamentals, JSON Patch, and practical diff workflows for debugging/migrations. This article addresses snapshot testing — a testing methodology built directly on JSON (or JSON-like) structural diffing — and why understanding the diffing underneath snapshot tests explains both their value and their most common frustration.

What a snapshot test actually does

A snapshot test works roughly as follows:

1. Run some code that produces output (a rendered component's structure, an API response, a function's return value — anything that can be serialized to JSON or a JSON-like representation)
2. The first time the test runs, the output is saved as a "snapshot" — a stored JSON file representing "what the output looked like at this point"
3. On subsequent runs, the new output is compared against the saved snapshot — using, fundamentally, a structural diff (the same kind of comparison covered in the previous articles)
4. If the diff is empty (no differences) — the test passes: "output is unchanged from the saved snapshot"
5. If the diff is non-empty — the test fails, and the diff is shown to the developer — who must decide: is this difference a bug (the code now produces wrong output) — or an intentional change (the code correctly now produces different, updated output, and the snapshot should be updated to match)?

Why this is powerful: catching unintended changes anywhere in a large structure

Snapshot testing's core value: it catches any difference, anywhere in a (potentially large, deeply-nested) output structure — without requiring the test-writer to have anticipated, in advance, every specific field that might change.

Compare to traditional, "assertion-based" testing: expect(result.user.name).toBe("Alice"), expect(result.user.age).toBe(30), etc. — each assertion checks one specific value. If the code changes such that result.user.email unexpectedly changes (a field no assertion was checking) — traditional assertion-based tests, checking only name and age, wouldn't notice — but a snapshot test, comparing the entire result structure, would flag the email difference — because the structural diff covers everything, not just the fields someone thought to assert on.

Why this is frustrating: "everything changed" diffs from small, intentional changes

The flip side of "catches everything": a small, intentional change — e.g., adding a new field to every item in a returned array — produces a diff showing every item in the array as "changed" (each item now has an additional field it didn't have before) — even though, conceptually, this is one simple, intentional change ("we added a new field"), not "N separate changes, one per array item."

For a large array (recall the previous article's discussion of array-diff cascading) — this single, intentional change can produce a diff that's pages long — every item showing the same, repetitive "+ new field" addition. A developer reviewing this diff — recognizing that it's "just" the same intentional change, repeated N times — often simply approves/updates the snapshot without carefully reviewing each repetition — because reviewing each of N identical repetitions provides no additional information beyond reviewing the first one.

This "rubber-stamping" — approving a large, repetitive diff based on recognizing the pattern, without line-by-line review of every occurrence — is, in itself, reasonable for truly repetitive, pattern-consistent changes — **but it also means: if one of the N array items, amid the otherwise-repetitive diff, contains a DIFFERENT, unintended change (a genuine bug, hiding among the expected, repetitive additions) — a developer rubber-stamping the overall "looks like the same pattern, N times" diff might miss that one, different, buried change.

"Snapshot update" workflows: the diff becomes the new baseline

When a snapshot test fails, and the developer determines the new output is correct (an intentional change) — the snapshot is updated to match the new output — typically via a command/flag that overwrites the stored snapshot file with the current output.

This means: the diff, once "approved," becomes the new "no diff" baseline — future test runs compare against this updated snapshot — if the code later changes again — the new diff is against this updated baseline, not the original.

A practical implication: snapshot updates should be reviewed as part of code review (the updated snapshot file, itself, is typically a file in version control — its changes appear in diffs/pull-requests, just like code changes) — **a pull request that includes snapshot updates is, effectively, saying "here's the (JSON) diff of what changed in this output, as a result of my code changes — please review whether THIS diff represents intended behavior."

If snapshot updates are committed without this review (e.g., a developer runs "update all snapshots" to make failing tests pass, without examining what changed, and commits the result) — the snapshot tests no longer provide meaningful protection — they'll "pass" because they're now comparing against whatever the (possibly buggy) current output is — the test suite reports "green," while the underlying output might have genuinely, unintentionally regressed.

Reducing diff noise: "inline snapshots" and "property matchers"

Some testing frameworks offer techniques to reduce the "everything changed" noise problem:

Excluding volatile fields: if a structure includes fields that are expected to differ on every run (timestamps, randomly-generated IDs, etc.) — these fields can be excluded from the snapshot comparison (or replaced with placeholder values before comparison) — avoiding the snapshot test failing on every run simply because "the timestamp is different this time," which, while technically "a diff," isn't meaningful — related, conceptually, to "Vary"-style exclusions — deciding, upfront, "these specific fields aren't part of what we're checking."

Smaller, more focused snapshots: rather than one enormous snapshot covering an entire, complex output — multiple, smaller snapshots, each covering a more focused portion of the output — reduces the "everything changed" cascade for any given, localized change — though at the cost of needing more individual snapshot files/assertions to cover the same overall surface.

How to use the JSON Diff tool on sadiqbd.com

1. For reviewing snapshot-test failures: paste the old (saved snapshot) and new (current output) JSON — the structural diff output is, effectively, what a snapshot-testing framework shows you, just in this tool's presentation rather than the testing framework's
2. For large, repetitive diffs (the "every array item changed" pattern): use the diff to confirm the pattern is, indeed, consistent across all items — and specifically check whether any individual item deviates from the otherwise-repetitive pattern — this manual "scan for the outlier" check is precisely what "rubber-stamping" skips, and what catching bugs-hidden-in-repetitive-diffs requires
3. Before updating a snapshot: review the diff (via this tool, or the testing framework's own diff display) as carefully as you would review any other code change — snapshot updates are code changes, and deserve the same review attention

Frequently Asked Questions

Is snapshot testing a "replacement" for traditional, assertion-based tests, or a complement? Generally considered a complement, not a replacement — snapshot tests excel at "catch any unintended change, anywhere in a complex structure" — but, as discussed, can generate noisy diffs for intentional changes, and rely on developers carefully reviewing updates. Traditional assertions (expect(x).toBe(y)) remain valuable for specific, important invariants that should be checked explicitly, with clear, targeted failure messages — regardless of whether the broader output structure happens to match a snapshot. Many test suites use both: snapshot tests for "broad, catch-anything" coverage of complex outputs, plus targeted assertions for specific, critical properties that warrant explicit, named checks regardless of snapshot status.

Is the JSON Diff tool free? Yes — completely free, no sign-up required.

Try the JSON Diff tool free at sadiqbd.com — compare JSON snapshots and review structural differences for testing and debugging.