Snapshot Testing
What a Snapshot Test Does
toMatchSnapshot() renders a component, serializes its output to text, and saves it to a snapshot file the first time the test runs. On every subsequent run, Jest compares the new output against the saved snapshot and fails the test if anything differs.
Note: Snapshot tests are best for catching UNINTENDED changes — they don't tell you WHAT is correct, just whether something changed.
Warning: A first run always passes by creating the snapshot — review the initial snapshot file carefully to confirm it's actually correct.
Example: What a Snapshot Test Does
// Run in your local React project (npm install required)
import { render } from '@testing-library/react';
import Card from './Card';
test('Card renders correctly', () => {
const { container } = render(<Card title="Hello" />);
expect(container).toMatchSnapshot();
});⚠️ This example uses an npm package with no CDN build available here — run this in your local React project.
Reviewing a Snapshot Diff
When a snapshot test fails, Jest shows a diff between the saved snapshot and the new output. You must read this diff and decide: was this change intentional (in which case you update the snapshot) or a real bug (in which case you fix the component instead)?
Note: Treat a failing snapshot the same way you'd treat a failing code review comment — investigate before accepting the change.
Warning: Blindly running the 'update snapshots' command whenever a test fails defeats the entire purpose — it would silently accept real bugs as the new expected output.
Example: Reading and Updating a Snapshot Diff
$ npx jest
FAIL src/Greeting.test.js
✕ renders a greeting (12 ms)
- Snapshot
+ Received
- <h1>Hello, Guest</h1>
+ <h1>Hello, World</h1>
# after confirming the change is intentional:
$ npx jest -u
PASS src/Greeting.test.js
1 snapshot updated.⚠️ Run this command in your terminal.
When to Use (and Avoid) Snapshots
Snapshots work best for small, stable components where any change is meaningful and easy to review. For large, frequently-changing components, snapshots tend to produce huge diffs that are hard to review carefully, making them less useful than targeted assertions about specific behavior.
Note: Prefer specific assertions (like screen.getByText(...)) for behavior you care about, and reserve snapshots for smaller, more stable presentational components.
Warning: A giant snapshot of a complex page makes even a tiny, correct change produce an overwhelming diff that's tempting to approve without really reading.
Example: When to Use (and Avoid) Snapshots
// Run in your local React project (npm install required)
// Good snapshot candidate: small, stable
test('Icon renders', () => {
const { container } = render(<Icon name="star" />);
expect(container).toMatchSnapshot();
});
// Less ideal: a whole complex Dashboard page — prefer targeted assertions there instead- Blindly running 'update snapshots' whenever a test fails, without actually checking whether the change was intentional.
- Snapshotting huge, complex component trees where a tiny unrelated change produces a massive, unreadable diff.
- Committing a stale snapshot file that no longer matches intentional recent changes.
- Snapshot tests save a serialized representation of rendered output and compare future runs against it.
- toMatchSnapshot() creates the snapshot file on first run, then compares against it on subsequent runs.
- A failing snapshot test means the output changed — you must confirm if that change was intentional.
- Snapshot files should be reviewed like code changes, not blindly regenerated.
Requires npm install jest (built-in snapshot support) — runs in Node, not this browser sandbox.
Chapter Quiz — Complete all 9 topics to unlock
0/9 topics done
Complete these topics first: