BackStopJS – drugie narzędzie z cyklu visual regression testing

BackStopJS – Jest to framework dostępny na githubie, który rozwijany jest przez społeczność, wytworzoną obok tej inicjatywy. Służy on do tworzenia testów wizualnej regresji aplikacji www.

Wspominałem o BackStopJS w pierwszym wpisie o narzędziach do wizualnej regresji (link). Jest to framework, którego głównie używa przy testach wizualnej regresji.

Plusy

• Open source – rozwijany jest przez aktywną społeczność.
• Wspiera parallel – krótki czas dużej ilości sprawdzeń.
• Testy tworzy się w  dość łatwy sposób – tak naprawdę po instalacji łatwo jest wdrożyć każdego w tworzenie tego typu scenariuszy.

Minusy

• Zdarzają się (czasami) problemy z niektórymi selectorami na stronie.
• Czasami są problemy z instalacją przez NPM na linuxie przez phantomjs’a, ale możemy tak jak w tym poście korzystać z BackStopJS w obrazie dockerowym, który działa poprawnie (Dzięki temu, że BackStopJS jest w kontenerze jest dużo mniejsze prawdopodbieństwo, że coś nie będzie działać, bo kontener zawiera dobrą wersję nodejs, npm, oraz phantomjs).
• Polecam popróbowanie z przeglądarkami, niektóre mają wsparcie dla parallel, inne mają z tym problem.

Obecne przeglądarki, które są wspierane

• PhantomJs (Wsparcie będzie wyłączane, przez pojawienie się Puppeteera).
• Chrome (Chromy)
• SlimerJS (Firefox)
• Puppeteer

Instalacja linux – Na OVH

Przechodzimy do instalacji BackStopJS na naszej maszynie linuxowej. W moim przypadku korzystam z VPS, który mam na OVH.

Czemu OVH?

• Jest relatywnie tani, możemy za kilkadziesiąt złotych miesięcznie mieć dość wydajną maszynę.
• Stabilny – dość dobry uptime (nawet gdybyśmy myśleli o nim jako o serwerze produkcyjnym do BackStopJS, powinien się jak najbardziej sprawdzić.

Czego potrzebujemy?

Komputer/serwer z systemem:

• Windows,
• Linux,
• MacOS

Mamy możliwość zainstalowania BackStopJS przynajmniej na dwa sposoby.

Jeżeli nie chcemy korzystać z Dockera:

Zainstalowany NodeJS oraz package manager NPM. Najlepiej w najwyższej wersji.

Jeżeli chcemy skorzystać z Dockera:

Zainstalowany Docker na jednym z ww. systemów.

Co polecam?

Z obu sposobów korzystam. Docker ma ten plus, że dość szybko możemy BackStopJS zainstalować. Plusem Dockera jest także to, że szybko możemy usunąć dany kontener Dockera. Bardzo rzadko się zdarza, że dany obraz Dockerowy nie działa.

Docker nadaje się do m.in. testowania różnego rodzaju frameworków i pozwala mieć do nich szybki dostęp.

BackStopJS i Docker?

Pobieramy najnowszą wersję obrazku z BackStopJS.

docker pull backstopjs/backstopjs

Następnie dodajemy alias w systemie (Ubuntu), który pozwoli nam mieć dostęp do komendy backstop, który uruchamia BackStopJS.

alias backstop=’docker run –rm -v $(pwd):/src backstopjs/backstopjs “$@

Jeżeli zainstalujecie BackStopJS przy pomocy NPM np. na Windowsie, zostanie dodana zmienna środowiskowa path ze ścieżką do BackStopJS i również, gdy użyjecie komendy backstop w konsoli, będzie mieli do niego dostęp.

Jak zainstalować BackStopJS przy użyciu NPMa?

Potrzebujemy NodeJs oraz NPM (manager pakietów dla NodeJs).

Instalowanie globalnie backstopjs.

npm install -g backstopjs

Uruchomienie BackStopJS

Gdy wpiszemy backstop (W przypadku gdy mamy dodany alias dla obrazu dockerowego lub gdy mamy backstopa zainstalowanego z npm).

Naszym oczom ukazuje się proste menu z dostępnymi opcjami do uruchomienia.

Tworzymy folder w tym miejscu, w którym chemy.

mdkir backstop-learning

cd backstop-learning

W tym miejscu użyjemy komendy backstop init, która inicjalizuje potrzebne pliki dla BackStopJS.

backstop init

Jakie to są pliki?

BackStopJs tworzy foldery:

• backstop_data
• backstop.json

W folderze backstop_data mamy:

• engine_scripts

Po wykonaniu komendy backstop init w folderze backstop_data mamy stworzony folder engine_scripts. Gdzie dodane są podstawowe skrypty, z których korzysta BackStopJS.

Backstop.json – plik, w którym umieszczamy konfiguracje do stron, które chcemy porównać. Domyślnie wygląda on tak:

Potencjalne błędy

Instalowałem wiele razy BackStopJS i z mojego doświadczenia wynika, że czasami zdarzają się błędy związane z phantomjsem. Co w tym przypadku należy zrobić? Polecam zainstalować osobno phantomjs np. z apt-get’a. (Na windowsie tego błędu nie spotkałem).

Również pamiętajcie o prawach użytkowników, jeżeli instalujecie coś globalnie.

BackStopJS – opcje konfiguracji

Plikiem, który służy nam do konfiguracji BackStopa jest backstop.json

Zaczynamy od ustalenia nazwy dla naszego zestawu testów. Służył do tego parametr id. Gdy już to zrobimy, następnie przechodzimy do ustalenia rozdzielczości, które chcemy sprawdzić podczas testów. Sugeruje podać kilka popularnych rozdzielczości dla desktop’a oraz mobile’a. Możecie również za pomocą google analytics dowiedzieć się, która z waszych platform cieszy się największą popularnością.

Następnie przechodzimy do zdefiniowania interesujących nas scenariuszy

Polecam również określać w labelu dokładnie jaki ekran chcemy wziąć pod uwagę i co w nim sprawdzamy – ułatwia to bowiem analizę wyników naszych testów.

Również w tym miejscu możemy wskazać cookies do jakiegoś miejsca w systemie, gdzie potrzebna jest np. autoryzacja i dzięki wskazaniu cookies’a możemy również przetestować ten obszar.

Dwa ważne parametry konfiguracyjne to:

• “url:” – jest adresem do stagingu naszej strony. Oczywiście, jeżeli tak przyjmiemy, referenceURL również może nim być tylko jeżeli ustalimy, że “url:” to adres stagingu naszej stron to trzymajmy się tego we wszystkich scenariuszach.
• “referenceUrl:”-  jest to adres naszej produkcji, jeżeli dokonamy approve to BackStopJS, będzie traktował nasze screenshoty jako poprawne i wyjściowe.

Dzięki temu jeszcze przed deployem możemy upewnić się, czy obszary, które są dla nas ważne nie mają regresji w wyglądzie strony.

Ważne: Dzięki temu testerzy manualni mają więcej czasu na eksploracje / ciekawe edge case niż regresja wizualna strony, która w niektórych przypadkach jest trudna do zrealizowania.

Przydatne opcje konfiguracji

Wymusza na nas, żeby elementy, które będą znajdywane miały na obu środowiskach tę samą wielkość.

Przydatną opcją jest możliwość ukrycia selectora – jeżeli mamy jakąś sekcje na stronie, która jest zależna np. od użytkowników (komentarze) to ukrycie pozwoli nam uniknąć false-postive’ów.

Przydatna opcja, ale trzeba używać ją z rozwagą, bo mogą wam zdarzyć się widoki, które mają kilka lub kilkanaście elementów o danym selectorze, ale niektóre mogą nie być widoczne, i może zdarzyć się otrzymanie błędu.

Możemy zdefiniować kilka selectorów, które nas interesują. Przykład:

[“h1”, “.title”, “.author”],

Ustawiamy jaki próg błędu, jesteśmy w stanie zaakceptować pomiędzy screenami. Trzeba zważyć na to, że wartość brana jest na podstawie rozdzielczości, wiec 0.1 z rozdzielczości wynoszącej 1920 x 1080 jest nie wielkim obszarem, ale już z 640 x 320 nie jest wcale tak małym.

Browser tworzy nam raport w htmlu. Domyślnie w katalogu backstop_data/html_report.

W paths ustalamy ścieżki dla naszych screensotów, raportu. Domyślnienie są to:

Polecam potestować różne ustawienia dla asyncCaputureLimit. Do tego celu warto mieć jakiś serwer (chmura / vps/ dedyk) – możecie zacząć od małego serwera, ale dużo, zależy od tego jak szybko chcecie mieć generowany raport. Zauważcie, że przeglądarki potrafią pobierać zauważalną ilość pamięci RAM, więc gdy myślimy o doborze serwera trzeba mieć to na uwadzę. Oczywiście możemy robić to również na lokalnej maszynie. Jednak dzięki osobnemu serwerowi cały zespół może korzystać z BackStopJS (np. umieszczając również swoje konfiguracje) + nasza lokalna maszyna nie jest obciążana.

BackStopJS – Uruchamianie testów

Do dyspozycji mamy cztery komendy:

backstop reference – tworzy nam screenshoty dla strony, którą podaliśmy w referenceURL oraz dla selectorów, które tam umieściliśmy.

backstop approve – mamy możliwość zaakceptowania tych screenshotów, jeżeli są to screenshoty, które dla nas oznaczają wyjściowe środowisko (poprawne).

backstop test – tworzy screenshoty dla środowiska, które podaliśmy w url.

backstop openReport – pozwala nam uruchomić ostatni raport w przeglądarce. ( komenda backstop test uruchamia raport w przeglądarce po zrobieniu screenshotów).

Jesteśmy w folderze backstop-learning uruchamiamy konsole.

backstop reference

backstop approve

backstop test

Po uruchomieniu komendy backstop test, tworzony jest raport HTML (oczywiście, jeżeli mam dodaną opcję “browser” w sekcji “report”. Domyślnie jest ona dodana).

Gdy strona posiada jakieś wizualne różnice różnice to widzimy je w raporcie.

Mój plik konfiguracyjny:

Dlaczego warto mieć BackStopJS na serwerze?

Ja używam raportu, który sprawdza dla mnie 300 kluczowych selectorów – tworzy się on w około 5 minut, a sprawdzam 4 rózne kluczowe rozdzielczości, więc szybkość tego sprawdzenia jest dość wysoka. Możemy również dodać notyfikacje na Slacka z testów BackStopJS, które uruchamiają się po wgraniu zmian na staging. Polecam potestować różne konfiguracje, przeglądarki, aby otrzymać satysfakcjonujący nas wynik.

Przykladowe scenariusze użycia:

Najczęściej spotykaną sytuacją jest posiadanie przynajmniej dwóch środowisk.

Jedno to staging/develop gdzie trzymamy wersje naszej aplikacji po wszystkich code review oraz testach.  Jednak również przed ostatecznym wypuszczeniem możemy dodać testy wizualnej regresji, które mogą sprawdzić, czy nie doszło do wizualnej regresji naszej aplikacji.

Porównywanie środowisk po każdym commicie

Widziałem pomysły na porównywanie środowiska testowego z obecną produkcją po każdym commicie. Na pewno, jeżeli planujecie zmiany w layoucie, to warto w tym miejscu porównać – czy najważniejsze miejsca wyglądają, tak jak miały wyglądać. Jak wiemy czasami zmiana w jednym miejscu, może mieć wpływ na miejsce, o którym nie pomyślimy (przez złożoność kodu), więc warto mieć pokryte najważniejsze miejsca w naszym systemie, o kluczowym znaczeniu biznesowym.

Kiedy jeszcze warto użyć BackStopJS?

Warto wziąć z Google Analytics lub innego narzędzia tego typu top 100 linków odwiedzanych przez waszych klientów. Możecie stworzyć taką konfigurację, która pokryje te przypadki. Dzięki temu, że możemy w BackStopJS ukrywać niektóre selectory, nie będziecie otrzymywać false-positvów.

Jak ze stabilnością BackStopJS?

Co ciekawe framework jest dość stabilny, używam go już dłuższy czas i tak naprawdę kilka razy miałem sytuacje, że musiałem uruchomić go jeszcze raz. Warto wybierać dobre locatory dla elementów, które chcemy wziąć do sprawdzenia.  Uważałbym z używaniem opcji SelectorExpansion, co prawda wydaje się ciekawą możliwość oznaczenia wszystkich selectorów danego typu, ale problemy mogą pojawiać się, gdy dany selector nie jest widoczny (dla BackStopJS), a znajduje się w kodzie html.

Gdzie trzymać pliki konfiguracyjne?

Polecam utworzyć repozytorium Git’a, a w nim foldery dla poszczególnych konfiguracji.

Podsumowanie

Dlaczego warto korzystać z BackStopJS? BackStopJS ma wiele zalet między innymi aktywne community – jest open source. Dość szybko możemy go skonfigurować i zainstalować u nas.