Czym jest visual regression? To przydatna metoda testowa, która sprawdza, czy w naszej aplikacji nie wystąpiła żadna regresja wizualna. Najczęściej sprowadza się to do porównania dwóch wersji aplikacji (np. środowiska staging ze środowiskiem testowym), poprzez wykonanie zrzutów ekranu całej strony lub wybranych elementów (na podstawie selektora lub selectorów HTMLowych). Następnie biblioteki testowe porównują obrazy piksel po pikselu, aby wykryć ewentualne różnice.

Grafika przedstawiająca tę ideę:

Kiedy takie testy są przydatne?

Kiedy mamy kluczowe strony sprzedażowe (tzw. landing pages) dla różnych lokalizacji i języków, ich ręczne sprawdzanie staje się bardzo czasochłonne, a przy większej skali – praktycznie niemożliwe. Poza tym warto wprowadzić takie testy dla naszych najważniejszy strony nawet gdy one bezpośrednio nie wpływają na sprzedaż, ale np. wpływają na wizerunek strony.

Warto zastosować automatyczne testowanie wizualne, ponieważ:

• To szybki sposób na sprawdzenie, czy po wprowadzeniu nowych zmian, np. w układzie strony, nie pojawiły się nieoczekiwane błędy wizualne w innych miejscach.
• Metoda ta jest szczególnie przydatna przy zmianach interfejsu lub rebrandingu – pomaga upewnić się, że wszystko działa i wygląda poprawnie po wdrożeniu nowych elementów graficznych.

Jakie potencjalne wyzywania możemy spotkać przy tego typu testach?

• Czcionki mogą być różnie renderowane w zależności od systemu operacyjnego i przeglądarki.
• Zróżnicowane rozdzielczości ekranu mogą powodować błędy w wyświetlaniu elementów na stronie.
• Istnieje ryzyko, że zbyt częste zatwierdzanie nowych baseline’ów spowoduje pomijanie faktycznych błędów wizualnych.
• Przy częstych zmianach w interfejsie użytkownika konieczne jest ciągłe aktualizowanie baseline’ów, co zwiększa koszt i czas utrzymania testów.
  Zarządzanie wynikami testowymi – przy pewnej skali może być to czasochłonne i zasobożerne.

Playwright wyróżnia się tym, że funkcjonalność visual regression jest dostępna „out of the box”. Dodatkowo istnieje kilka narzędzi pozwalających na rozszerzenie podstawowych możliwości visual regression w Playwright. Oczywiście podobne rozwiązania są dostępne również w innych narzędziach, takich jak Selenium, Cypress czy inne systemy do automatycznego testowania interfejsu użytkownika. Warto także wspomnieć o BackStopJS – narzędziu, z którego korzystałem komercyjnie i które również dobrze spełnia swoją rolę.

https://github.com/garris/BackstopJS

Co ciekawe, w BackStopJS pod spodem działa również m.in. Playwright, co pozwala na wykorzystanie jego możliwości do testów wizualnych. Dzięki temu BackStopJS oferuje wsparcie dla nowoczesnych przeglądarek i bardziej niezawodne wykonywanie zrzutów ekranu.

Jakie są możliwości w Playwright?

• Rozwiązanie out-of-the-box – Playwright umożliwia dodanie sprawdzeń potencjalnej regresji wizualnej w istniejących testach bez konieczności dodania skomplikowanej dodatkowej konfiguracji.
• Visual Regression Tracker – Zaawansowane narzędzie, które składa się z kilku kontenerów Docker. Umożliwia integrację z wieloma narzędziami do testowania, nie tylko z Playwrightem. Ponieważ jest to rozwiązanie open-source, możemy je wdrożyć we własnej infrastrukturze serwerowej.
• Rozwiązania komercyjne – Na rynku istnieje wiele komercyjnych narzędzi, takich jak Applitools czy Percy (obecnie należący do BrowserStack). Często są one bardzo wygodne w użytkowaniu, jednak ich koszty mogą być zbyt wysokie przy intensywnym korzystaniu.

Jakiej apliakcji użyjemy do tego artykułu?

Użyjemy aplikacji The Internet:

Do rozwoju naszych umiejętności jako testerów automatyzujących polecam stronę https://the-internet.herokuapp.com/, która oferuje wiele nowoczesnych kontrolek oraz przykłady mniejszych stron internetowych takich jak np. ekran logowania. Świetnie nadają się one do ćwiczenia umiejętności testowania automatycznego.

Te przykłady są idealne do praktyki z narzędziami takimi jak Playwright, Selenium, Cypress i innymi narzędziami do automatyzacji testów.

Przykładem, który wykorzystam w tym tekście, jest tzw. shifting content – czyli przypadek, w którym po każdym odświeżeniu strony obrazek zmienia swoje położenie. Dodatkowo możemy sami zdefiniować, o ile pikseli obrazek ma się przesunąć oraz dodać element losowości, który określi, gdzie obrazek będzie widoczny na stronie.

Kod naszego testu wygląda następująco:

Jest to prosty test, który wchodzi na stronę, a następnie na końcu wykonuje sprawdzenie. Test uruchamiam dwukrotnie, aby zauważyć różnice – obrazek na stronie za każdym razem pojawia się w innym miejscu. Do tego celu używam opcji pixel_shift=200, dzięki czemu za każdym uruchomieniem obrazek jest przesunięty o inną liczbę pikseli na stronie.

Należy pamiętać, że te testy przy pierwszym uruchomieniu zakończą się błędem, ponieważ nie istnieje jeszcze tzw. baseline – czyli domyślny zrzut ekranu, do którego można porównać wyniki testów. Aby utworzyć taki baseline, wystarczy uruchomić testy lub skorzystać z dedykowanej metody do jego utworzenia.

npx playwright test --update-snapshots

Która zrobi nam snapshot wyjściowy dla tych testów.

Playwight stworzył trzy obrazki po uruchomieniu tego testu.

Inną możliwością na zrobienie porównania jest przekazanie w metodzie toHaveScreenshot nazwy pliku z naszym zrzutem ekranu, który ma zostać porównany. Może to być przydatne w sytuacjach, gdy musimy wyświetlić jakiś zasób, np. obrazek pobrany z innego serwisu i sprawdzić, czy rzeczywiście jest on dostępny w określonym miejscu na stronie.

Oprócz przydatnej opcji wykonywania zrzutu ekranu całej strony, czyli ustawienia fullPage: true, mamy tutaj również dostęp do innych ustawień, które mogą być wykorzystane w testach.

W jaki sposób możemy zmniejszyć lub zwiększyć „czułość” owych sprawdzeń?

Parametr maxDiffPixels odpowiada za to w jakim wymiarze różnice w pikselach jesteśmy w stanie zaakceptować, dla naszego testu automatycznego, im wyższa wartość tym większa ilość pikseli może się różnić na stronie.

Dodawanie tzw. Maski dla wybranych elementów?

Kiedy użyjemy parametru mask w naszym teście automatycznym, zostanie nałożona tzw. maska. Oznacza to, że zamiast wybranego elementu (w tym przypadku elementu z selektorem h3) w jego miejscu pojawi się określony kolor. Domyślnym kolorem maski jest różowy.

Za pomocą parametru maskColor można samodzielnie zdefiniować kolor maski. W moim przykładzie również ustawiłem kolor różowy, aby pokazać, w jaki sposób możemy dowolnie określać interesujący nas kolor. Dodatkowo parametr mask przyjmuje tablicę elementów, co pozwala na zdefiniowanie wielu elementów, które chcemy zamaskować – nie musi to być tylko jeden element

Dodatkowo parametr mask przyjmuje tablicę elementów, co pozwala na zdefiniowanie wielu elementów, które chcemy zamaskować – nie musi to być tylko jeden element.

Wyłączenie animacji dla strony?

Zgodnie z dokumentacją Playwright istnieje możliwość skorzystania z parametru animation: ‘disabled’, która powoduje, że animacje nie będą brane pod uwagę podczas wykonywania zrzutu ekranu. Jest to bardzo przydatne, ponieważ współczesne aplikacje webowe często zawierają wiele dynamicznych animacji i ruchomych elementów.

W przypadku stron z dużą liczbą takich elementów warto rozważyć wykonywanie zrzutów ekranu tylko dla wybranych fragmentów strony, zamiast całej strony. Dzięki temu nasze testy będą bardziej odporne na przypadkowe błędy wynikające z dynamicznych zmian na stronie.

Testowanie różnych rozdzielczości

Różne rozdzielczości:

Warto w tego typu testach korzystać z różnych rozdzielczości oraz systemów, aby uzyskać jak największe pokrycie testowe. Testowanie na różnych rozdzielczościach, a także symulowanie rozdzielczości urządzeń mobilnych, można zrealizować poprzez edycję ustawień w pliku playwright.config.ts.

Inne przydatne ustawienia

Oprócz korzystania z innych rozdzielczości, które możemy ustawić w pliku playwright.config.ts, możemy tutaj zdefiniować także inne ustawienia, takie jak threshold oraz maxDiffPixelRatio, obowiązujące globalnie dla wszystkich sprawdzeń w naszym rozwiązaniu.

Dla przypomnienia, w pliku konfiguracyjnym możemy również zdefiniować nie tylko rozdzielczość, ale także przeglądarkę oraz jej wersję. Dzięki temu możemy sprawdzić, czy pomiędzy różnymi wersjami przeglądarek nie występuje żadna wizualna regresja.

Co zrobić w sytuacji, gdy chcemy zwiększyć pokrycie testów o różne systemy operacyjne i bardziej specyficzne konfiguracje?

Jeśli chcemy zwiększyć liczbę przeglądarek oraz różnorodność konfiguracji, możemy skorzystać z usług firm oferujących przeglądarki w chmurze. Dzięki temu możemy pokryć szerokie spektrum wymagań dotyczących różnych środowisk.

Alternatywnym rozwiązaniem jest skorzystanie z Moona – komercyjnej, lecz przystępnej cenowo opcji, która umożliwia uruchamianie przeglądarek w chmurze w ramach własnej infrastruktury.

Summary

„W tej pierwszej części serii o testach regresji wizualnej w Playwright omówiliśmy, jak zacząć. W kolejnym artykule przedstawię Visual Regression Tracker — narzędzie open-source, które oferuje więcej funkcji niż domyślny mechanizm regresji wizualnej w Playwright. Bądźcie czujni!