Testowanie migawkowe HTML

Testy snapshot zapisują wynik renderowania komponentu lub strony podczas pierwszego uruchomienia, a podczas kolejnych uruchomień porównują nowy wynik z zapisanym snapshotem. Każda zmiana w wyniku HTML powoduje niepowodzenie testu do momentu celowej aktualizacji snapshotu.

Matcher toMatchSnapshot() w Jest serializuje wartość (w tym JSX wyrenderowany do HTML) i porównuje ją z zapisanym plikiem. npx jest -u aktualizuje snapshoty, gdy zachodzą zamierzone zmiany. Testy pełnią funkcję siatki bezpieczeństwa chroniącej przed niezamierzonymi zmianami renderowania.

Storybook Test Runner uruchamia każdą historyjkę i tworzy snapshoty jej wyniku za pomocą axe (dostępność) oraz serializacji DOM. W połączeniu z Chromatic dodaje do tego regresję wizualną — różnice na poziomie pikseli oprócz różnic w DOM.

Percy i Chromatic zapisują wyrenderowane strony jako obrazy i pokazują różnice wizualne. Wykrywają regresje CSS, których snapshoty DOM nie wykrywają (zmianę czcionki, modyfikację marginesu, zmianę koloru). Snapshoty DOM (tanie i szybkie) należy łączyć ze snapshotami wizualnymi (droższymi i kompleksowymi).

Snapshoty, które zmieniają się „zbyt łatwo”, stają się źródłem szumu. Należy unikać tworzenia snapshotów dla niestabilnych wartości (dat, identyfikatorów, losowych kluczy). W przypadku pól, które zgodnie z założeniami różnią się między uruchomieniami, należy używać matcherów właściwości Jest (expect.any(String)). Snapshoty powinny być małe i skoncentrowane.

Różnice w plikach snapshotów w pull requestach są pełnoprawnym materiałem do przeglądu. Osoby dokonujące przeglądu sprawdzają, czy zmiany w DOM są zamierzone i pożądane, wykrywając przypadkowe skutki kaskadowe „prostej” zmiany CSS. Różnice w snapshotach należy traktować tak samo jak każdą inną różnicę.

Tworzenie snapshotów rozbudowanych renderów całych stron jest kruche — każda drobna zmiana prowadzi do ogromnego diffa. Twórz snapshoty na poziomie komponentów: każdego Buttona, każdej Card i każdego FormField. Renderowanie na poziomie strony lepiej pokryć testami regresji wizualnej.

Wybierz sposób serializacji: pełny HTML, uproszczony DOM, tylko propsy albo drzewo dostępności. Każdy format wykrywa inne regresje. W przypadku komponentów UI pełny HTML zapewnia najdokładniejsze sprawdzenie; w przypadku logiki sterowanej przez propsy wariant obejmujący tylko propsy jest tańszy i rzadko powoduje fałszywe alarmy.

Najczęstszą przyczyną jest refaktoryzacja, która generuje równoważny, ale inaczej zbudowany HTML. Sprawdź diff: jeśli zmiana jest zamierzona i poprawna, zaktualizuj snapshot. Jeśli jest nieoczekiwana, napraw kod, który leży u jej podstaw. Nigdy nie uruchamiaj bez sprawdzenia jest -u.

Narzędzia do testów regresji wizualnej renderują widoki w wielu przeglądarkach i zgłaszają różnice charakterystyczne dla konkretnych przeglądarek. Wykorzystaj je do wykrywania CSS-u, który renderuje się inaczej w Safari niż w Chrome — to częsty problem w przypadku nowych funkcji układu na wczesnym etapie ich wdrażania. Bez snapshotów między przeglądarkami takie regresje są wykrywane dopiero podczas ręcznych testów QA.

Testy snapshotowe są niezbędne, ale niewystarczające. Wykrywają niezamierzone zmiany w renderowaniu, ale nie wykrywają błędów logiki (na przykład tego, że kliknięcie przycisku nie wykonuje właściwej czynności). Połącz je z testami jednostkowymi sprawdzającymi zachowanie oraz testami end-to-end dla ścieżek użytkownika — każda warstwa wykrywa inne rodzaje błędów.

Testy snapshotowe są szybkie — porównują ciągi znaków lub pliki. Testy regresji wizualnej są wolniejsze (renderują piksele i porównują obrazy, często w wielu przeglądarkach). Uruchamiaj snapshoty przy każdym buildzie CI; testy regresji wizualnej uruchamiaj przy każdym PR-ze, ale zależnie od budżetu CI być może nie przy każdym commicie.

Dlaczego testy snapshotowe DOM-u zwykle uzupełnia się testami regresji wizualnej, takimi jak Percy lub Chromatic?

Testowanie snapshotowe zapisuje wyrenderowany HTML przy pierwszym uruchomieniu i sygnalizuje każdą zmianę przy kolejnych uruchomieniach. Używaj Jestu toMatchSnapshot dla DOM-u komponentów, Storybook Test Runner dla stories oraz Percy/Chromatic do regresji wizualnej na poziomie pojedynczych pikseli. Twórz snapshoty na poziomie komponentów, a nie całych stron, wykluczaj niestabilne wartości i dokładnie analizuj diffy w PR-ach. Łącz te testy z testami jednostkowymi i end-to-end, aby uzyskać pełne pokrycie.