Snapshot Testing

A snapshot test records the output of some code the first time it runs — rendered markup, a serialised object, a generated file — stores it alongside the test, and thereafter fails whenever the new output differs from the stored copy. It is a cheap way to cover surface area that would be tedious to assert on field by field, which is why it is common for UI component trees, API response shapes and code generators. The cost is that a snapshot test asserts that output has not changed, not that it is correct. That distinction produces the characteristic failure mode: a diff appears, the author does not read it closely, the update command is run, and a real regression is committed as an accepted snapshot. Large snapshots make this worse, because a genuine one-line problem is invisible inside three hundred lines of noise, and any unrelated change repaints the whole file in the diff. Practices that keep them useful: keep snapshots small and focused on one behaviour, review snapshot changes in code review exactly as carefully as source changes, never bulk-update, and exclude volatile content such as timestamps, random identifiers and ordering that is not guaranteed, since those produce flaky failures that teach the team to update without looking. And pair them with a few explicit assertions on the properties that actually matter — that the error field is populated, that the total equals the sum of the lines — because those state the intent, which a snapshot never does.