Development & Code · master area
Visual Regression Testing
Storybook state vs rendered pixel. The pipeline stage that catches drift the human eye stops seeing — and the only test the Designer reviews directly.
Owners: Developer, QA, Designer Phase it lives in: How We Build (Volume IV) The corpus principle this enacts: The pipeline catches a different chain level at each stage.
Where it lives in the chain
- How We Build · Testing · QA craft — the canon
- How We Build · The Pipeline · seven stages — visual regression is its own stage
How to do this
- Setup — every Storybook story is captured. Tooling (Chromatic, Percy, Loki, Playwright snapshots) doesn't matter — the discipline does.
- Practice — diffs block the PR. The PR author cannot rubber-stamp their own diff; Designer or QA approves the new baseline or rejects the regression.
- Related craft — Visual Regression Baseline — the design-side perspective
What good practice looks like
A PR adjusts the PrimaryButton border-radius from 4px to 6px. Eleven Storybook stories show diffs. The CI fails the PR. The Designer reviews the eleven diffs, confirms the intended change, approves the new baselines in one batch. The PR merges with the new baselines. No story in production drifts silently.
A PR introduces a console.log that triggers no failures. No visual diffs surface. The PR merges. Visual regression caught nothing because there was nothing to catch — the test is silent unless drift exists, and that silence is itself a signal: the surface didn't change.
The cost of visual regression is the time to review approved diffs. The cost of not having it is the polish degrading by inches across every release, until the product looks one degree off from its own design system.
Related crafts
- Visual Regression Baseline — the design discipline
- Storybook — the catalogue being tested
- Component Development — where baselines are born