What is snapshot testing?

Question

Accepted Answer

**Snapshot testing** captures a "snapshot" of some output (commonly a UI component's rendered output or a data structure) and compares future runs against it — flagging when the output changes. It's useful for detecting unintended changes, but has limitations to understand.

## How snapshot testing works

```text
1. First run → the test RECORDS the output (e.g. a rendered component) as a SNAPSHOT file
2. Later runs → COMPARE the current output to the saved snapshot:
   → MATCHES → pass; DIFFERS → fail (the output changed)
3. If the change is INTENTIONAL → UPDATE the snapshot (review the diff, then accept)
```

```js
// Jest snapshot test (e.g. a React component)
test('renders correctly', () => {
  const tree = render(<Button label="Click" />).toJSON();
  expect(tree).toMatchSnapshot();    // compares to the stored snapshot
});
```

## Uses and benefits

```text
✓ Detect UNINTENDED CHANGES — flags when output changes unexpectedly (UI, serialized data)
✓ FAST to write — no manual assertions for complex output; auto-captures the expected result
✓ Good for UI components (catch unexpected rendering changes), config, large data structures
```

## Limitations (use carefully)

```text
⚠️ Snapshots don't verify CORRECTNESS — they capture whatever output exists (even if WRONG);
   they only detect CHANGE, not that the output is RIGHT
⚠️ BLINDLY UPDATING snapshots (jest -u without reviewing) → defeats the purpose (accepting
   broken output) — a common bad habit
⚠️ Large/brittle snapshots → change often, get rubber-stamped, low value
→ Use for change detection; keep snapshots small/focused; REVIEW snapshot diffs;
  don't rely on them alone (combine with real assertions for behavior).
```

## Why it matters

Understanding snapshot testing is valuable because it's a **commonly-used technique** (especially for UI) that's useful when applied well but problematic when misused, so understanding both its value and limitations is important practical knowledge.

Snapshot testing — capturing output (commonly a rendered UI component or data structure) and comparing future runs against the stored snapshot — is **useful for detecting unintended changes**: it flags when output changes unexpectedly (catching accidental UI rendering changes or data structure changes), is **fast to write** (auto-capturing expected output without manually asserting every detail of complex output), and suits UI components, configuration, and large data structures.

Understanding these benefits explains its popularity, especially in UI testing.

However, understanding the **limitations is critically important** to use it well: snapshots **don't verify correctness** — they capture whatever output exists (even if it's wrong), only detecting *change* not *rightness* — so a snapshot can lock in buggy output.

The **biggest pitfall is blindly updating snapshots** (running the update command without reviewing the diff), which defeats the purpose by accepting potentially-broken output — a common bad habit.

Large, brittle snapshots that change often get rubber-stamped and provide little value.

Understanding the proper use — for change detection, keeping snapshots small and focused, **reviewing snapshot diffs** carefully, and not relying on them alone (combining with real behavior assertions) — reflects mature judgment that avoids the common misuse.

Since snapshot testing is widely used (especially for UI) and is useful for change detection but easily misused (locking in wrong output, blindly updating), and since understanding both its value and its important limitations enables using it well, understanding snapshot testing is valuable, practically-relevant knowledge — a common technique to understand correctly, where appreciating its limitations (change detection, not correctness) and proper use (reviewing diffs, not blindly updating) is as important as the technique itself, reflecting sound testing judgment.