Visual and snapshot regression

Visual regression testing compares a screenshot of your interface against an approved one and flags the differences.

Snapshot testing is the same idea applied to serialised output rather than pixels. A stored copy of rendered markup or a data structure, compared on later runs.

Both catch a class of defect nothing else does. A layout collapse on one viewport. Text overflowing its container. An element that disappeared because a CSS change removed it. Nobody writes an assertion for those, because nobody thinks of them.

Both also produce false positives at a rate that determines whether the practice survives. The whole skill is scoping and noise control.

The terms you will hear

• Baseline. The approved image or snapshot that future runs are compared against.
• Diff. The visual difference between the baseline and the current run.
• Threshold. How much difference is tolerated before a test fails.
• Masking. Excluding regions that legitimately change, so they cannot cause a diff.
• Approval. Accepting a diff as the new baseline. The step where discipline is won or lost.
• Flaky diff. A difference caused by rendering variation rather than a real change.

Where the noise comes from

Understanding this is most of the practice.

• Fonts and rendering. The same page renders differently on macOS and Linux, so run in a container and always the same one.
• Dynamic content. Dates, names, avatars, order numbers. Freeze them or mask them, which is the determinism problem again.
• Animation and transitions. Capture after they finish, or disable them for the run.
• Lazy loading and images. Wait for the network to settle, or the screenshot catches a half-loaded page.
• Scrollbars and viewport chrome. Small, constant, and enough to fail a strict threshold.

How to scope it so it survives

1. Pick a handful of targets. The components with real layout risk and the two or three pages that matter commercially. Not every page.
2. Two viewports, not six. One mobile, one desktop. Add more only when a defect demonstrates the need.
3. Prefer component-level over full-page. A component diff is small and obvious, and it pairs with the component tests you already have. A full page diff is often one pixel of reflow.
4. Freeze the data. Fixed dates, fixed names, seeded content. Then mask anything left that moves.
5. Disable animation for the run, and wait for fonts and images before capturing.
6. Set a threshold deliberately and record why. Zero tolerance produces noise, and a loose threshold hides real shifts.
7. Require a named approver. Approval is a decision, so it needs an owner, exactly like accepting a known issue.

A worked setup

For example, here is one narrow, surviving setup.

The last defect is the argument for the practice. The API returned the payment lines correctly, every API test passed, and the page simply stopped rendering them. Only a picture catches that.

How to show you know it

• A scoped list with a reason. Nine components and three pages beats thirty-four pages nobody reviews.
• A noise budget. "Zero to two diffs per pull request." It is the number that predicts whether the practice lives.
• A defect only a picture could catch. The missing payment lines is the canonical example.
• A masking list. Showing which regions you excluded, and why, demonstrates you understand the failure mode.