E2E Testing

Playwright visual regression testing for critical flows

Use Playwright screenshot testing to protect your most important user journeys—without turning every PR into a screenshot approval marathon.

Join the waitlist

Component vs E2E visual testing

Visual testing happens at two levels, and understanding when to use each prevents wasted effort.

Component visual testing (like Storybook visual testing) captures isolated UI states. It's fast, stable, and great for design systems.

E2E visual testing captures components in context—real pages, real data, real flows. It's slower and noisier, but catches integration issues that component tests miss.

Most teams benefit from both: comprehensive component coverage plus targeted E2E visual tests for critical journeys.

Pick the right flows

Not every page needs E2E visual testing. Focus on flows where visual bugs cause real business impact.

Checkout and payment

High-stakes flows where visual bugs directly impact revenue. Worth the investment to protect.

Onboarding and signup

First impressions matter. Catch layout breaks before they hurt conversion.

Core navigation states

Headers, sidebars, menus. These appear on every page—a regression here is everywhere.

Empty and error states

Often overlooked but frequently broken. Visual tests catch missing fallbacks.

Start small—five to ten flows maximum. Expand coverage once you've proven the workflow is sustainable.

Stabilise your screenshots

E2E environments are inherently variable. Screenshots will differ between runs unless you actively control for variance.

Disable animations

CSS transitions and JavaScript animations cause timing-dependent failures. Disable them in test mode.

Mock time and data

Freeze timestamps, seed random values, and use deterministic test fixtures. Dynamic content breaks diffs.

Fixed viewport

Always specify exact viewport dimensions. Default browser sizes vary across environments.

Consistent fonts

Web fonts render differently across systems. Either use system fonts or ensure fonts are fully loaded before capture.

These aren't nice-to-haves. Skip them and you'll spend more time investigating false positives than actual bugs. See reducing visual testing flakiness for more techniques.

Keeping CI fast

Visual tests add time to your pipeline. Plan for it:

  • Parallelise: Run visual tests across multiple workers or machines
  • Be selective: Run full visual suite on PRs to main; smoke tests on feature branches
  • Separate concerns: Consider running visual tests in a separate pipeline stage that doesn't block fast feedback

For more on CI integration, see visual testing in CI.

A sane approval loop

Detecting visual changes is easy. Deciding what to do about them is hard.

Build a workflow where diffs are small, ownership is clear, and approvals happen quickly. Large batches of unreviewed diffs become "approve all" buttons—defeating the purpose.

See approval workflow patterns for structured approaches, and designer-approved testing for bringing design context into the loop.

Quick checklist

  • Identify 5-10 critical user flows worth visual protection
  • Configure consistent viewport and browser settings
  • Disable animations and transitions in test mode
  • Mock timestamps, random values, and dynamic content
  • Set up deterministic CI environment (container recommended)
  • Establish baseline approval workflow before going live

Related guides

Visual regression testing fundamentalsHow to reduce visual testing flakinessStorybook visual testing for design systemsVisual testing in CI pipelinesVisual diff approval workflows

Frequently Asked Questions

Is Playwright screenshot testing reliable?
Yes, when configured correctly. Playwright provides pixel-level comparison and cross-browser support. Reliability issues usually stem from environmental differences (fonts, animations, dynamic content) rather than Playwright itself.
Why are screenshots different locally vs CI?
Different operating systems render fonts differently. GPU acceleration, screen scaling, and browser versions also vary. Use containerised CI environments with fixed configurations to match local development, or accept that CI is the source of truth.
Should I commit screenshots to git?
It's one approach, but large repos with many screenshots can become unwieldy. Consider external storage for baselines, especially for teams with many contributors or large test suites. What matters most is version control and traceability.
How do I test multiple viewports with Playwright?
Use Playwright's viewport configuration to run the same tests at different screen sizes. Focus on breakpoints where your layout actually changes—typically mobile, tablet, and desktop widths.
How do I avoid false positives in E2E visual tests?
Disable animations, mock dynamic content, wait for network idle and fonts to load, use fixed timestamps, and run in consistent containerised environments. Most false positives come from timing or environmental variance, not actual bugs.
What's the best granularity for E2E visual tests?
Test critical user journeys, not every page. Full-page screenshots are often too noisy. Consider element-level screenshots for specific components, or mask dynamic regions to focus on stable UI areas.
How do Playwright visual tests fit with component tests?
They serve different purposes. Component visual tests (like Storybook) verify isolated UI contracts. E2E visual tests verify that components work correctly when integrated into real flows. Use both for comprehensive coverage.
Should visual tests block deployments?
It depends on your confidence level and failure rate. Start with reporting-only mode to build trust. Once tests are stable and meaningful, consider blocking—but always provide escape hatches for urgent fixes.

Join the waitlist for reliable E2E visual testing

Get early access