gotchatypescriptModerate
Snapshot testing: use for stable serializable output, not as a lazy assertion
Viewed 0 times
snapshot testingtoMatchSnapshotjest snapshotssnapshot anti-patterninline snapshot
Problem
Developers use Jest
toMatchSnapshot() on large React component trees or entire API response objects. Every UI refactor forces snapshot updates. Reviewers approve snapshot diffs without understanding them. Broken snapshots are updated with --updateSnapshot without investigation.Solution
Use snapshots only for stable, serializable output that is tedious to write out manually: AST nodes, CLI output, SVG strings, small config objects. For React components, prefer explicit assertions with Testing Library queries. If you must snapshot a component, snapshot only the part that matters.
Why
Snapshots that are too large become noise. Developers stop reading them and update blindly. The snapshot file becomes a liability — it grows without bound and its diffs obscure real regressions.
Gotchas
- toMatchInlineSnapshot() is preferable for small snapshots — the expected value lives in the test file and is visible in review
- Snapshots are not a substitute for assertions — they verify that output has not changed, not that it is correct
- Dynamic values in snapshots (timestamps, UUIDs, memory addresses) must be replaced with expect.any(String) matchers
- Committing large snapshot files in PRs is a code review anti-pattern — split into smaller units
Revisions (0)
No revisions yet.