Chapter 13. Visual Regression Testing

Tell me if this is a familiar scene: you’ve been working on your website contact form for the last few weeks, trying to tweak and nudge the form fields until they look exactly like the Photoshop mockup. You’ve meticulously compared every margin, padding, border, and line height. Your lead generation tool is now “pixel perfect,” and the product owner agrees: “This is the contact form to end all contact forms.” With this code securely committed, you move on to your next task and stop having recurring nightmares about browser drop-down rendering discrepancies.

Weeks later, you are surprised to find a familiar sight in your ticket queue: the contact form. Some designer, business analyst, or quality assurance engineer took a ruler to your design and compared it to the latest Photoshop comp, and found a list of discrepancies.

But why?! How?! Did someone break your code? Did someone change the design? Tracking down the culprit is a luxury you do not have time to pursue. So you sit down with a list of tweaks and get to work hoping that this is the last time you’ll have to touch this contact form, but resign yourself to the fact that you’ll probably see it a few more times before the site launches.

The Usual Suspects

My favorite sound in the world is the cry of a decision maker as they scream how “feature X is totally broken!” Translated into developer terms, this usually means that a few of the font styles are incorrect, or that some vertical rhythm ...

Get Frontend Architecture for Design Systems now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.