Your Storybook visual regression suite has been green for months, yet visual bugs keep reaching production. What classes of regression does story-driven visual testing structurally miss?

## Why green is not the same as covered Story-driven visual testing compares each story against its own baseline. That means the suite's failure mode is *silence*, not red: anything outside the set of captured stories is not judged and not reported. A team reading "0 changes" as "nothing looks wrong" is reading a much narrower statement than it appears to be. ## Class 1 — states with no story The most common gap and the least interesting technically. A component gains a compact density, a loading skeleton, a truncated-title case; no story is added; the suite keeps comparing the three states it already knew. Nothing about the tooling flags this, because a missing render target is indistinguishable from an unchanged one. The countermeasure is procedural: new visual state ships with its story, and every escaped visual bug earns a backfilled story for the state it slipped through. ## Class 2 — composition This is the structural one. Isolation is the source of the model's determinism and attribution, and it is exactly what removes the page. Bugs that only exist in composition include: - A card that overlaps a sticky header because a stacking context in the page changed. - Two components side by side that each look correct but together overflow their row. - A component inside a narrow grid cell whose internal layout only works at the width the story happened to use. - Spacing that is correct in the component but doubles or collapses against the container's own spacing. No story can see any of these, because in a story the neighbours do not exist. This is not a gap you can close with more stories of the same kind; it is closed by a different layer of test. ## Class 3 — content and data A story's props are literals someone typed. Production strings are longer, shorter, in other scripts, sometimes missing. Lists are empty or have four hundred rows. Numbers have more digits than the mock. Every one of those changes layout, and none of them is represented unless someone deliberately wrote a story for it. Composed stories built from generous fixtures are especially misleading: they look like realistic coverage and are not. ## Class 4 — environment drift A component in Storybook inherits whatever the preview provides: the preview's own resets, whatever global stylesheet the configuration loads, whatever theme provider a global decorator wraps stories in, and the width of the preview frame. The application inherits a different set. When those diverge — the app adds a global rule, or a token layer that Storybook does not load — the component ships looking different from every baseline you hold, and the suite stays green throughout because it compared the story to the story. The mitigation here is concrete and worth naming: load the application's real global styles and theme layer into the Storybook preview, so the two environments are the same environment. That converts the whole class from invisible to detected. ## What to do about it The answer an interviewer is listening for is layering, not repair. - Keep story coverage as the wide, cheap, high-attribution base layer. It is very good at what it does: catching regressions in a component's own rendering, per state. - Make the preview environment match the app's, so the base layer's baselines mean what you think they mean. - Add a **small** set of page-level visual checks on genuinely composed surfaces — the busiest route, one dense layout, one shell with global chrome. Small is the operative word: these are the noisy, hard-to-attribute checks, and their value is entirely in catching composition drift that nothing else can see. - Pair the visual suite with behavioural component tests, because a page can be pixel-identical and functionally broken. Visual regression only ever answers "does it still look like this", never "does it still work". ## The framing to avoid Weak answers treat this as a tooling failure and reach for a different diff service. The gaps above are consequences of the *unit of capture*, not of how images are compared, and changing tools reproduces every one of them.