Testing

Visual regression testing with Playwright in Drupal workflows

šŸŽ§ Listen to every article back to back

A standard automated test checks whether a button works. Visual regression testing with Playwright shows before deployment whether a Drupal update moved a form, menu, focus indicator or important component into the wrong place.

How it works

Playwright opens the page in a browser, takes a screenshot and compares it to a saved baseline image. If the pixel difference exceeds the allowed threshold, the test fails. In Drupal maintenance, this is useful before deploying core, module or theme updates.

On first run a baseline image is created. All future screenshots are compared against it. When design changes intentionally, the baseline is updated manually.

Visual testing helps when:

  • design changes often;
  • the site must work on mobile and desktop;
  • components come from several systems;
  • previous releases caused layout defects;
  • accessibility depends on visible focus and readable text.

What not to over-test

Not every page needs screenshot comparisons. It is better to start with critical journeys: front page, form, cart, service page and one content page.

Screenshot tests are sensitive to minor changes such as font rendering, an icon or a cosmetic layout shift. If tests fail too often without a real defect, the team stops trusting them. A good rule is to use them where a visual regression costs more than a false alarm.

Integration into a CI/CD pipeline

The most value comes when visual tests run automatically after every change. Playwright runs them in headless mode ā€” no browser window opens, and tests run quickly on a CI server too.

A typical setup:

  1. Baseline screenshots are saved in the repository.
  2. After each change, screenshots are compared in CI.
  3. When a difference appears, the developer gets a visual diff showing where the change occurred.
  4. For an intentional change, update the baseline and commit it with the code change.

WebPro uses visual checks as part of automated testing when they actually reduce release risk. In Drupal projects, this fits well with maintenance, Drupal audits and larger Drupal upgrades.

Subscribe via RSS
Kaido Toomingas, WebPro technical leadWebPro Company OƜ Technical lead: Kaido Toomingas

Need Drupal help?

If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.

Contact us