Podstawy testów regresji wizualnej

Testowanie regresji wizualnej (VRT) automatycznie wykrywa niezamierzone zmiany wizualne między wersjami kodu, porównując wyrenderowane zrzuty ekranu piksel po pikselu. Wykrywa regresje CSS — przesunięcia układu, zmiany kolorów i nieprawidłowe odstępy — których testy jednostkowe w ogóle nie wykrywają.

VRT wykonuje bazowe zrzuty ekranu komponentów lub stron, a następnie po zmianach w kodzie wykonuje nowe zrzuty i porównuje je z bazą. Różnice są wyróżniane na obrazie różnicowym. Programiści analizują różnice i zatwierdzają zamierzone zmiany albo naprawiają niezamierzone regresje.

Różnicowanie pikselowe porównuje obrazy piksel po pikselu — jest czułe, ale podatne na fałszywe alarmy wynikające z wygładzania krawędzi i różnic w renderowaniu subpikselowym. Narzędzia do różnicowania strukturalnego (Applitools AI) porównują zamierzenia wizualne, a nie dokładne piksele, ograniczając liczbę fałszywych alarmów wynikających z różnic w renderowaniu czcionek.

Zatwierdzone zrzuty ekranu stają się nową bazą. Bazowe zrzuty należy przechowywać w systemie kontroli wersji (Git LFS w przypadku dużych obrazów) lub w dedykowanej usłudze chmurowej. Każdy PR pokazuje różnice względem bazy, a opiekunowie zatwierdzają albo odrzucają zmiany wizualne w ramach przeglądu kodu.

Testy VRT na poziomie komponentu sprawdzają pojedyncze komponenty interfejsu w izolacji (za pośrednictwem Storybook). Testy VRT na poziomie strony sprawdzają całe strony w prawdziwej przeglądarce. Testy komponentów są szybsze i bardziej ukierunkowane, natomiast testy stron wykrywają problemy z układem na poziomie integracji między komponentami.

Należy testować wszystkie stany wizualne: domyślny, hover, focus, active, disabled, loading, error, empty i pełny. Stany hover wymagają symulacji za pomocą JavaScriptu (page.hover() w Playwright). Brak pokrycia stanów tworzy luki w wykrywaniu regresji w stanach interaktywnych.

Należy renderować zrzuty ekranu w wielu przeglądarkach (Chrome, Firefox, Safari) i dla wielu obszarów widoku (telefon, tablet, komputer). Różnice w renderowaniu przeglądarek mogą powodować fałszywe alarmy — należy używać osobnych baz dla każdej przeglądarki i konfigurować progi różnic, aby tolerować znane różnice w renderowaniu.

Renderowanie czcionek nieznacznie różni się w zależności od kombinacji systemu operacyjnego, przeglądarki i GPU. Należy używać spójnych środowisk CI (Docker + konkretna wersja Chrome), aby wyeliminować fałszywe alarmy powodowane przez środowisko. Usługi VRT w chmurze automatycznie zapewniają spójność środowiska.

Dynamiczna zawartość — znaczniki czasu, awatary użytkowników, reklamy i losowe dane — powoduje fałszywe alarmy. Przed przechwyceniem zrzutu ekranu należy zamaskować dynamiczne regiony jednolitym kolorowym obszarem. Większość narzędzi VRT obsługuje selektory elementów do maskowania.

Proszę uruchamiać VRT w CI dla każdego PR-a. Kompilacja powinna kończyć się niepowodzeniem po wykryciu niezatwierdzonych różnic wizualnych. Różnice wizualne należy kierować także do osób zajmujących się projektem, a nie wyłącznie do zespołu inżynierskiego — zmiany wizualne są w takim samym stopniu kwestią projektu, jak i inżynierii.

VRT zapewnia najwyższy zwrot z inwestycji w bibliotekach komponentów i systemach projektowych, w których spójność wizualna jest cechą produktu. W przypadku często zmienianych stron marketingowych koszt utrzymywania bazy może przewyższać wartość wykrywania regresji.

Dlaczego testy regresji wizualnej generują fałszywe alarmy wynikające z różnic w renderowaniu czcionek?

Testy regresji wizualnej wykrywają regresje w CSS i układzie strony, porównując zrzuty ekranu między różnymi wersjami kodu. Skuteczne testy VRT wymagają spójnych środowisk, pokrycia stanów, maskowania treści dynamicznych oraz procesu przeglądu, który przekazuje różnice osobom weryfikującym projekt — dzięki temu stają się wspólnym narzędziem zapewniania jakości, a nie tylko automatyczną bramką.