Screenshot testing: Gotta Catch 'Em All

Introduction When developing medium and large applications, UI/UX testing becomes a challenge. To verify the design and form interactions, we often need to understand the entire business flow, like how to navigate from Sign In Form to Add PayPal payment details form. This frequently requires: Creating test users Configuring necessary permissions Populating the database with test data In such conditions, design validation becomes a struggle for developers, designers, and project managers. Decouple UI/UX Testing from the Backend I believe that UI and UX validation should be independent from the backend. There is no reason to understand the entire business process just to: Open User Profile view; Verify that the save button is enabled only after valid input; Ensure error messages appear appropriately when invalid data is entered. How to Achieve This? The only solution is to develop custom dev tools at least that: Mock API calls Modify application stores Enable quick navigation within the UI This allows: ✔️ Rapid validation of new frontend features; ✔️ UI/UX testing without backend dependencies; ✔️ Comparing current designs with previous versions. Presets, dynamically change backend response, navigate between views. With dev tools, the desire to automate visual regression testing comes to mind. This leads us to the next topic: screenshot testing. Screenshot testing is the name for the assertion, not the type of testing. Screenshot testing could be e2e (for example playwright or selenium support screenshot snapshots), or unit tests. However E2E is slow, moreover they require a lot of business knowledge and sometimes infrastructure knowledge from developers. And do we really want to run the e2e test after changing the button padding? I don’t think so. The front-end unit test should care about consistency of design after changing the button padding. But true is FRONTEND TESTS DON’T CARE ABOUT STYLES AT ALL It doesn’t make any sense for me, because even if it is just a small padding, it could create such a mess. Why do frontend developers ignore that? That is how I was working: testing-library - utils for testing React jest for running test node - javascript environment The problem in such an approach is: I don’t see the browser in the list. Where are we testing frontend units? Inside the virtual js-dom, it even doesn’t have 100% compatibility with the Browser DOM. Application behavior heavily depends on the device and environment:

Mar 29, 2025 - 09:01

Introduction

When developing medium and large applications, UI/UX testing becomes a challenge. To verify the design and form interactions, we often need to understand the entire business flow, like how to navigate from Sign In Form to Add PayPal payment details form.
This frequently requires:

Creating test users
Configuring necessary permissions
Populating the database with test data

In such conditions, design validation becomes a struggle for developers, designers, and project managers.

Decouple UI/UX Testing from the Backend

I believe that UI and UX validation should be independent from the backend. There is no reason to understand the entire business process just to:

Open User Profile view;
Verify that the save button is enabled only after valid input;
Ensure error messages appear appropriately when invalid data is entered.

How to Achieve This?

The only solution is to develop custom dev tools at least that:

Mock API calls
Modify application stores
Enable quick navigation within the UI

This allows:
✔️ Rapid validation of new frontend features;
✔️ UI/UX testing without backend dependencies;
✔️ Comparing current designs with previous versions.

Presets, dynamically change backend response, navigate between views.

With dev tools, the desire to automate visual regression testing comes to mind. This leads us to the next topic: screenshot testing. Screenshot testing is the name for the assertion, not the type of testing. Screenshot testing could be e2e (for example playwright or selenium support screenshot snapshots), or unit tests.
However E2E is slow, moreover they require a lot of business knowledge and sometimes infrastructure knowledge from developers. And do we really want to run the e2e test after changing the button padding? I don’t think so. The front-end unit test should care about consistency of design after changing the button padding. But true is

FRONTEND TESTS DON’T CARE ABOUT STYLES AT ALL

It doesn’t make any sense for me, because even if it is just a small padding, it could create such a mess. Why do frontend developers ignore that? That is how I was working:

testing-library - utils for testing React
jest for running test
node - javascript environment

The problem in such an approach is: I don’t see the browser in the list. Where are we testing frontend units? Inside the virtual js-dom, it even doesn’t have 100% compatibility with the Browser DOM. Application behavior heavily depends on the device and environment: