Visual regression test
Screenshots your UI, compares it to an approved baseline, and fails when pixels move. Catches the CSS change that broke a different page.
See it
What it is
A visual regression test screenshots your UI, compares each shot against a stored baseline image, and fails when enough pixels differ. It catches the class of bug no assertion covers: the button still works, the text is still there, but a shared CSS token nudged the whole card three pixels and squashed the footer on another page.
Typical setup: Playwright's toHaveScreenshot, BackstopJS, or a hosted reviewer like Chromatic or Percy that posts a side-by-side diff on the pull request. You approve intended changes, which promotes the new screenshot to the baseline. Reach for it on design systems, marketing pages, and anything where 'looks correct' is the actual requirement.
Gotcha: these are the flakiest tests you will ever own. Font rendering, GPU antialiasing, scrollbars, and animation timing all differ between your Mac and CI Linux, so baselines must be generated in the same container that runs them. Freeze animations, stub dates and random data, mask avatars and ad slots, and set a small pixel threshold, or you will spend Fridays approving diffs of nothing.
Ask AI for it
Add visual regression tests with Playwright. For each key page and component state, navigate, wait for fonts and network idle, disable CSS animations and transitions, freeze the clock to a fixed date, mask dynamic regions (avatars, timestamps, embeds), then assert expect(page).toHaveScreenshot() with a small maxDiffPixelRatio. Run at 3 viewport widths (375, 768, 1440), store baselines per platform, and generate them inside the same Docker image CI uses so font rendering matches.