Playwright’s built-in visual testing (toHaveScreenshot) works well in small projects: it’s fast, simple, and local.
But once you start using it in a team with multiple contributors, it quickly becomes fragile:
- Snapshots live in Git and often conflict
- You compare against your last push, not production
- Test runs must be triggered manually to update screenshots
- Results are hard to review and trust without a proper UI
- Flaky diffs creep in due to platform and rendering inconsistencies
I wrote an article that breaks down the strengths and limits of Playwright’s model, and why it starts to fail at scale. It also explains how shifting to a CI-based approach (like Argos) changes the baseline, stabilizes results, and adds a real review layer.
API changes frequently result in broken applications, largely due to the difficulty in monitoring their ripple effects. This article discusses the practical benefits of using Zod to enforce API stability and detect regressions through visual testing with Argos.
But once you start using it in a team with multiple contributors, it quickly becomes fragile:
- Snapshots live in Git and often conflict - You compare against your last push, not production - Test runs must be triggered manually to update screenshots - Results are hard to review and trust without a proper UI - Flaky diffs creep in due to platform and rendering inconsistencies
I wrote an article that breaks down the strengths and limits of Playwright’s model, and why it starts to fail at scale. It also explains how shifting to a CI-based approach (like Argos) changes the baseline, stabilizes results, and adds a real review layer.