ReferenceIntermediate4-6 min reference
Visual Regression Testing
Visual regression testing catches unintended UI changes by comparing a screenshot against an approved baseline, pixel by pixel (or by perceptual diff). It catches what assertions miss — a shifted layout, a clipped element, a colour change. The hard part is keeping it from crying wolf. This sheet covers the concepts and anti-flake tactics; the tools are linked below.
How it works
- Capture a screenshot of a component/page.
- Compare it to the stored baseline.
- If they differ beyond a threshold, fail and surface the diff.
- A human approves intended changes, updating the baseline.
Key terms
| Term | Means |
|---|---|
| Baseline | The approved "correct" image |
| Diff | Highlighted pixels that changed |
| Threshold | Allowed difference before failing |
| Approve / accept | Promote a new image to baseline |
| Perceptual diff | Compares like a human eye, not raw pixels |
Taming flakiness (the whole game)
- Freeze dynamic content: dates, avatars, random data, ads, animations.
- Disable animations/transitions and wait for fonts/images to load.
- Pin the environment: same browser, viewport, and device-pixel-ratio (render in CI, not laptops).
- Prefer component-level snapshots over full-page — smaller, more stable.
- Mask or ignore known-dynamic regions.
Where it fits
Great for design systems and pages with rich layout. Not a substitute for functional tests — a button can look perfect and do nothing. Pair the two.
Common mistakes
- Baselining a flaky page → constant false diffs, then ignored failures.
- Mixing render environments (local vs CI) so fonts/anti-aliasing differ.
- Full-page snapshots that break on any tiny change.
- Auto-approving diffs without a human review (defeats the purpose).
// Related resources