Testowanie zrzutów ekranu to bardzo skuteczny sposób sprawdzania interfejsu aplikacji. Zrzuty ekranu mogą występować w testach komponentów, funkcji i aplikacji.
Za pomocą narzędzi innych firm możesz tworzyć testy z wykorzystaniem zrzutów ekranu z wykorzystaniem instrumentacji i testy lokalne. Jeśli używasz funkcji Utwórz, możesz użyć oficjalnego narzędzia do testowania zrzutu ekranu w narzędziu Compose Preview.
Definicja
Testy zrzutów ekranu polegają na zrobieniu zrzutu ekranu interfejsu i porównaniu go z poprzednio zatwierdzonym obrazem, zwanym „referencyjnym” lub „złotym”:
Jeśli obrazy są takie same, test kończy się powodzeniem. Jeśli występują między nimi różnice, narzędzie tworzy raport:
W raporcie masz 2 możliwe opcje:
- zauważyć błąd w nowym kodzie i go naprawić;
- Zatwierdź nowy zrzut ekranu i zastąp nim zdjęcie referencyjne.
Testy zrzutów ekranu mają inny proces niż zwykłe testy, ponieważ nieudany test nie zawsze oznacza, że wystąpił błąd.
Zalety
Zalety i testy zrzutu ekranu:
- Test ze zrzutami ekranu wykonuje wiele stwierdzeń na test. Na przykład jeden test może sprawdzać kolory, marginesy, rozmiary i czcionki.
- Test zrzutu ekranu jest znacznie łatwiejszy do napisania, zrozumienia i utrzymania niż równoważny test behawiorystyczny.
- Są one szczególnie przydatne podczas weryfikowania i wychwytywania regresji na różnych rozmiarach ekranu.
Wady
Testy zrzutów ekranu mają jednak też wady:
- Praca z obrazami referencyjnymi może być uciążliwa, bo duży projekt może skończyć się z tysiącami plików PNG.
- Różne platformy (Linux, Max i Windows) generują nieco inne zrzuty ekranu.
- Są one wolniejsze niż równoważne testy zachowania.
- Przeprowadzanie dużej liczby testów zrzutów ekranu może być przyczyną problemów, na przykład gdy pojedyncza zmiana wpływa na tysiące zrzutów ekranu.
W następnych sekcjach znajdziesz zalecenia dotyczące rozwiązywania tych problemów.
Ogranicz testy zrzutów ekranu do minimum
Należy zminimalizować liczbę testów zrzutów ekranu, a jednocześnie zmaksymalizować opinie i zasięg regresji.
Kombinacje różnych stanów interfejsu mogą bardzo szybko zwiększyć liczbę testów. Oto kilka sposobów na zweryfikowanie części interfejsu aplikacji:
- różne motywy.
- Używanie różnych rozmiarów czcionek
- w różnych rozmiarach ekranu lub ramach;
Jeśli zrobisz to w przypadku każdego komponentu, układu i ekranu aplikacji, uzyskasz tysiące plików ze zrzutami ekranu, z których większość nie będzie zawierać żadnych dodatkowych informacji zwrotnych.
Jeśli na przykład chcesz przetestować przycisk niestandardowy w jasnej i ciemnej tematyce oraz w 3 rozmiarach czcionki, nie musisz tworzyć kombinacji wszystkich tych opcji. Zamiast tego możesz wybrać tylko jeden motyw. Dzieje się tak, ponieważ sposób, w jaki przycisk reaguje na długie słowa, nie ma wpływu na motyw.
Przechowuj obrazy referencyjne
Obrazy referencyjne (lub złote) to zwykle pliki PNG, które można sprawdzić w kontroli źródła. Jednak Git i większość menedżerów źródeł kontroli źródeł są zoptymalizowane pod kątem plików tekstowych, a nie dużych plików binarnych.
Możesz zarządzać tymi plikami na 3 sposoby:
- Nadal korzystaj z git, ale staraj się zminimalizować wykorzystanie miejsca na dane.
- Użyj Git LFS.
- Do zarządzania zrzutami ekranu użyj usługi w chmurze.
Różnice między platformami
Testy zrzutów ekranu korzystają z interfejsów API niskiego poziomu, aby rysować określone funkcje, takie jak tekst czy cienie. Platformy mogą implementować te funkcje na różne sposoby. Jeśli pracujesz na komputerze Mac i zapisujesz nowe zrzuty ekranu wykonane lokalnie, na maszynie CI z systemem Linux możesz zobaczyć nieprawidłowe testy.
Ten problem można rozwiązać na 2 sposoby:
- Tolerancja małych zmian
- Zrzuty ekranu na serwerze
Tolerancja małych zmian
Większość bibliotek testowania zrzutów ekranu można skonfigurować tak, aby uwzględniać niewielkie różnice między dwoma zrzutami ekranu.
Możesz to zrobić na 2 sposoby:
- Skonfiguruj tolerancję na podstawie procentu zmodyfikowanych pikseli lub procentu łącznej różnicy w wartościach pikseli.
- Użyj inteligentnego narzędzia do porównywania – algorytmu, który porównuje zrzuty ekranu – aby zweryfikować podobieństwo strukturalne i semantyczne zamiast podobieństwa pikseli.
Wadą tego podejścia jest to, że może ono powodować wyniki fałszywie pozytywne i nie wykrywać błędów, które są poniżej progu lub błędnie uznane za wystarczająco podobne.
Zrzuty ekranu na serwerze
Aby korzystać z porównywacza zrzutów ekranu z zachowaniem pikseli, musisz się upewnić, że w testach zrzuty ekranu są wykonywane w tych samych warunkach. Możesz do tego użyć systemu ciągłej integracji (CI) lub usługi w chmurze.
Możesz na przykład utworzyć krok w przepływie pracy CI, który:
- Uruchamia testy zrzutów ekranu (konieczne tylko wtedy, gdy nie używasz dopasowania do perfekcji).
- Jeśli poprzedni krok się nie powiódł, rejestruje nowe zrzuty ekranu.
- zatwierdza nowe pliki w gałęzi.
Dzięki temu podejściu testy zrzutów ekranu nigdy nie będą się nie powieść w ramach CI, ale wprowadzą zmiany w Twoim imieniu. W ten sposób Ty i osoby sprawdzające zmiany możecie zaakceptować nowe zrzuty ekranu, scalając zmiany.
Narzędzia do testowania zrzutów ekranu
Pamiętaj o tych różnicach między dostępnymi narzędziami i bibliotekami do testowania zrzutów ekranu:
- Środowisko: testy lokalne uruchamiane na hoście lub testy z instrumentacją uruchamiane na emulatorze lub urządzeniu.
- Silnik renderowania: rozwiązania do tworzenia zrzutów ekranu po stronie hosta mogą używać Layoutlib (silnika renderowania Android Studio) do wyświetlania podglądów lub Robolectric Native Graphics (RNG).
- Frameworki oparte na Layoutlib skupiają się na renderowaniu komponentów statycznych, używając różnych stanów do wyświetlania różnych zachowań. Są one zazwyczaj łatwiejsze w użyciu.
- Frameworki, które integrują się z RNG, mogą korzystać ze wszystkich funkcji Robolectric, co umożliwia przeprowadzanie testów o większym zakresie.