{"id":62370,"date":"2026-03-19T16:19:13","date_gmt":"2026-03-19T20:19:13","guid":{"rendered":"https:\/\/app14743.cloudwayssites.com\/?p=62370"},"modified":"2026-03-19T16:19:14","modified_gmt":"2026-03-19T20:19:14","slug":"playwright-visual-testing-strategy","status":"publish","type":"post","link":"https:\/\/app14743.cloudwayssites.com\/blog\/playwright-visual-testing-strategy\/","title":{"rendered":"Engineering a Playwright-Native Developer Experience: One Flag, Three Strategies"},"content":{"rendered":"\n
\n

Hello everyone! I\u2019m Noam, an SDK developer on the Applitools JS-SDKs team. While my day-to-day focus is on core engineering, I work closely with our field teams and occasionally join technical deep-dive sessions with customers.<\/em><\/p>\n\n\n\n

In these conversations, we frequently encounter questions about performance and the engineering philosophy behind our integration. Specifically, there is often curiosity about how to make visual testing feel more \u201cPlaywright-native\u201d and natural to developers.<\/em><\/p>\n\n\n\n

In this post, I\u2019ll share the design logic behind these architectural choices so you can apply these patterns in your own CI pipelines in a way that fits your organization\u2019s needs.<\/em><\/p>\n<\/blockquote>\n\n\n\n

Adding unresolved<\/mark><\/code> to Playwright<\/strong><\/h2>\n\n\n\n

Integrating visual regression testing into Playwright requires combining two different status models: Playwright’s binary Pass\/Fail and the visual testing concept of unresolved<\/mark><\/code><\/strong>.<\/p>\n\n\n\n

In visual testing, instead of having two (passed and failed) states, there\u2019s an additional third state: unresolved<\/mark><\/code><\/strong>. This state indicates a difference was detected, but a human decision is required to determine if it is a bug or a valid change that should be approved as a new baseline.<\/p>\n\n\n\n

\u200bPlaywright doesn’t support this third state out of the box. Visual test maintenance using Playwright’s native toHaveScreenshot<\/mark><\/strong><\/code> API forces the developer into a cumbersome cycle requiring three separate test executions:<\/p>\n\n\n\n

    \n
  1. First, the developer needs to run to see the failure.<\/li>\n\n\n\n
  2. Then, they need to run with the --update-snapshots<\/mark><\/strong><\/code> flag to create new baseline images.<\/li>\n\n\n\n
  3. Then, most developers would run again to validate that everything works with the updated baseline as expected\u2014which isn’t always the case, because the Playwright native comparison method (pixelmatch<\/strong><\/mark><\/code>) tends to be very flaky, unlike Visual AI.<\/li>\n<\/ol>\n\n\n\n

    \u200bAfter this local cycle, the developer must commit the new baseline images to the repository\u2014bloating the git history\u2014and wait for a new CI execution to provide final feedback. For dev-centered organizations that focus on feedback loop velocity, this workflow is\u2026 suboptimal. Personally, I believe that’s one of the reasons visual testing isn’t as popular as it should be among Playwright users.<\/p>\n\n\n\n

    \u200bWhen we engineered the Applitools fixture, one of our goals was to support this Unresolved state natively, without disrupting Playwright\u2019s core lifecycle\u2014specifically its Worker Processes<\/strong> and Retry <\/strong>mechanisms.<\/p>\n\n\n\n

    The solution rests on two key engineering decisions: moving rendering to the background (async architecture) and giving developers control over the exit signal and performance tradeoffs (failTestsOnDiff<\/mark><\/strong><\/code>).<\/p>\n\n\n\n

    We don\u2019t block test execution when Applitools is rendering<\/strong><\/h2>\n\n\n\n

    The core value of visual testing lies in AI-based comparison to eliminate false positives and multi-platform rendering.<\/p>\n\n\n\n

    Architecturally, these processes are cloud-native services.<\/p>\n\n\n\n