Snapshot Testing
Test by comparing output against a committed golden file; any change forces an explicit decision.
Test by comparing output against a committed golden file; any change forces an explicit decision.
Snapshot testing captures the output of a function on a known input and stores it as a golden file. Every future run diffs the output against the stored snapshot. If they match, the test passes. If they differ, the test fails and forces a decision: was this change intentional or a regression? Intentional changes require updating the snapshot with an explicit commit. Unintentional changes surface before they reach production. The technique only works on deterministic systems: non-deterministic outputs produce flaky snapshots that fail unpredictably. The payoff is regression coverage of complex output structures without writing explicit assertions for every field.
How It Works
Call function with known seed or input → compare output to stored golden file → on mismatch, fail with diff → developer reviews diff, updates golden file if intentional, fixes code if not.
Example
A seeded PRNG campaign system replaced Math.random() throughout a pipeline, enabling snapshot testing across 73 encoding variants. Each variant produces identical output given the same seed. Any unintended behavioral change in any of the 73 variants surfaces as a snapshot diff rather than a silent regression.