You push a one-line CSS change, and a button on a completely different page quietly falls apart. No test fails, review didn’t catch it, and you hear about it from a user a week later. Every small team knows this bug.
The textbook answer is more unit tests. I manage a small dev team, and honestly, unit-testing every component and layout state is a luxury we don’t have. What we lean on instead is visual testing: screenshot the pages, compare them against known-good baselines, and flag the build when pixels move that shouldn’t. For the effort involved, nothing else I’ve tried comes close.
Why screenshots earn their keep#
The appeal is everything you don’t have to write. A visual test doesn’t assert on individual elements; it judges the page as a whole. Layout shifts, colour changes, broken responsive behaviour, overlapping elements — exactly the things that slip through code review and are miserable to cover with unit tests — all show up as a diff right in the PR.
Maintenance is close to nil, too. You set a baseline once, then it runs on every PR with the same result every time. Intentional UI change? Update the baseline and move on. Unintentional one? The diff is sitting in the PR, and nobody had to click through half the site to find it.
It doesn’t replace unit tests#
Unit tests verify logic; screenshots verify appearance. You want both eventually. But if you’re small and have to choose where the first hours go, visual tests buy more coverage per hour of setup than anything else. My rule of thumb: unit tests for the business logic that would genuinely hurt, visual tests for the rest.
That’s the whole system — baselines, diffs on every PR, and the occasional “yes, that was intentional” click. It catches more than it has any right to.
More information and useful links#
Visual Testing with Playwright#
Playwright’s snapshot testing docs: capture full pages or individual elements, compare against a baseline, and manage baseline updates when the UI changes on purpose. Visual Testing with Playwright
Best Practices for Testing with Playwright#
Playwright’s advice for tests that touch a database: isolate test data, clean up afterwards, and keep tests independent so the suite stays reliable. Best Practices for Testing with Playwright