How snapshots work
A snapshot test renders a component and saves its output to a file. On later runs the test compares the new render against the saved snapshot and fails if they differ. The first run records, every run after that verifies nothing changed unexpectedly.
- It captures markup or serialized output automatically.
- Failures show a diff between old and new output.
- You update the stored snapshot when a change is intended.
The tradeoff
Snapshots are cheap to write and catch unintended changes, but they assert nothing about correctness, only sameness. A huge snapshot is hard to review, and developers learn to update it blindly, which defeats the purpose.
- Good for: small, stable output where any change is meaningful.
- Risky for: large trees that change often and get rubber stamped.
- Better: small focused snapshots over giant full page ones.
Treat a snapshot diff as something to read, not auto accept. If updating snapshots becomes a reflex, prefer explicit assertions that state what should be true instead of merely what was rendered last time.
Key idea
Snapshots cheaply flag changed output but assert sameness not correctness, so keep them small and review every diff.