Automated visual regression testing for components

WHAT THIS TESTS The interviewer wants the full lifecycle of visual regression testing and an understanding of why it complements, rather than replaces, unit and integration tests, since CSS and rendering bugs slip past logic-focused tests.

A GOOD ANSWER COVERS First, render components in deterministic states. A common setup uses Storybook stories that capture each component variant and state, controlling data, fonts, and randomness so renders are stable. A visual testing tool, such as Chromatic, Playwright screenshots, or Percy, captures an image of each story. These images are compared pixel by pixel, or with perceptual diffing, against a stored baseline of approved images. In CI, on each pull request the pipeline builds the stories, captures fresh screenshots, and diffs them. If differences are found, the run is marked needs review and a report links to side-by-side or highlighted diffs. A human reviews: intended changes are accepted, which promotes the new image to the baseline, and unintended regressions are rejected, failing the check. To reduce flakiness you pin fonts, disable animations, freeze time, and run in a consistent browser and viewport.

COMMON WRONG ANSWERS Believing unit tests or DOM snapshot tests catch visual drift is wrong; they verify structure, not appearance. Auto-accepting all diffs defeats the purpose. Ignoring flakiness sources like animations and font loading produces noisy false positives. Storing baselines per developer machine rather than centrally causes inconsistent results.

LIKELY FOLLOW-UPS How do you minimize flaky diffs? How do you handle intentional design changes across many stories? Where are baselines stored and how are they versioned? How does this fit branch protection? What is the cost trade-off of running on every commit versus every pull request?

ONE CONCRETE EXAMPLE A developer tweaks Button padding. On the pull request, CI captures the Button stories, the tool flags a 4 pixel shift versus baseline, and posts a diff. The reviewer sees the change was intended, accepts it to update the baseline, and the check turns green; had a font change shifted an unrelated Card, the diff would have caught that regression too.