Snapshot test
The test records the output once, commits it, and fails whenever it changes. You then decide: real bug, or intended update?
See it
What it is
A snapshot test does not say what the output should be. It records whatever the output was the first time, commits that file, and fails on any later run where the output differs. The assertion is 'this did not change without you noticing', and the review happens in the diff: you look at the change and decide whether it is a bug or an intended update you accept by rerunning with -u. Jest popularized the name; Vitest, pytest plugins, and the wider golden-file and approval-testing family do the same thing.
It earns its keep where writing the assertions by hand would be miserable but a diff is instantly readable: rendered markup for a component, a serialized API response, generated SQL or code, a CLI's help text, a formatted error message. Inline snapshots (toMatchInlineSnapshot) are usually the better default for small outputs, because the expected value sits in the test file where a reviewer will actually see it instead of in a .snap file nobody opens.
The failure mode is rubber-stamping. When a snapshot is 400 lines and the suite is red, everyone runs -u and moves on, and now the test asserts nothing at all. Keep snapshots small enough to read in a code review, and update them one at a time. Second gotcha: anything nondeterministic (timestamps, UUIDs, random ordering, absolute paths) makes the snapshot fail forever, so freeze the clock and add property matchers or serializers. And note the boundary: a snapshot test diffs text or a serialized tree, while a visual regression test diffs actual pixels, so a CSS-only break sails straight through a DOM snapshot.
Ask AI for it
Add snapshot tests for [COMPONENT / FUNCTION] that stay reviewable. Use inline snapshots (toMatchInlineSnapshot) for anything under about 30 lines so the expected output lives in the test file, and external snapshots only for larger serialized output. Before snapshotting, make the output deterministic: freeze the clock to a fixed date, stub id and random generators, sort any unordered collections, and replace remaining volatile fields with property matchers. Keep each snapshot scoped to one meaningful unit rather than the whole page tree, and pair each one with at least one explicit assertion about the behavior that actually matters. Configure CI to fail on new or obsolete snapshots rather than writing them.