W artykule poruszę temat automatyzacji testów E2E aplikacji mobilnych, pisanych przy użyciu React Native. Rozwiązanie w nim zaprezentowane ma rację bytu w przypadku, kiedy aplikacja, którą mamy testować tworzona jest z myślą o iOS i Androidzie. W sytuacji, kiedy React Native jest wykorzystywane do stworzenia aplikacji na jedną platformę — lepiej pozostać przy rozwiązaniach jej dedykowanych.


Mateusz Bernat. QA Tech Lead w Acaisoft. Niedoszły polonista, od sześciu lat związany z testowaniem oprogramowania. Aktualnie Tech Lead zespołu QA w Acaisoft, gdzie zajmuje się, między innymi, tworzeniem frameworków do automatyzacji testów API oraz frontu aplikacji mobilnych i webowych.
W wolnym czasie biega (bo musi) i brzdąka na ukulele (bo lubi).


Rynek aplikacji mobilnych od lat rozwija się dynamicznie, osiągając w 2018 wartość ponad 65 mld $ (kwota ta dotyczy wyłącznie pobrań i płatności wewnątrz aplikacji!). Prawie drugie tyle wart jest rynek związany z ich wytwarzaniem. Pośród systemów operacyjnych na urządzenia mobilne, jedynymi liczącymi się graczami są obecnie Apple i Google, dzieląc go ~22% dla iOS i ~75% dla Androida. Ponadto środowisko Androida charakteryzuje się dużo większą fragmentacją (wynikającą ze znacznie niższego stopnia aktualizacji OS niż w przypadku iOS), stawiając przed zespołami QA dodatkowe wyzwania.

Te miliardy dolarów czekają do podziału na tych, którzy najszybciej dostarczą najlepszą jakościowo (i oczywiście interesującą) aplikację — stąd tak duże zapotrzebowania na rozwiązania, które pozwolą na przyspieszenie procesu wytwarzania oprogramowania. Jednym z nich jest, zaproponowany przez Facebooka, React Native, pozwalający na pisanie natywnych aplikacji na iOS i Androida przy użyciu Javascript. Dzięki niemu, programiści mogą, tworząc jeden kod, przygotować aplikację, która będzie (lub powinna) działać na obu platformach.

Wydawać by się mogło, że React Native to kolejna odsłona aplikacji hybrydowych — to wrażenie jest jednak pozorne, React Native nie wykorzystuje WebView i oferuje znacznie większe możliwości niż aplikacje hybrydowe.

Rys 1. Renderowanie natywnych widoków aplikacji React Native

Zatem, nasz wspomniany kontekst to: znaczące skrócenie etapu programowania w procesie wytwórczym, połączone z koniecznością przetestowania aplikacji na rozdrobnionym rynku mobilnym (nie zapominajmy przecież o mnogości urządzeń, nie tylko wersji systemów operacyjnych!).

Co z tym zrobisz, testerze?

Przyspieszenie programistycznego etapu wytwarzania aplikacji mobilnych nie idzie niestety w parze z przyśpieszeniem etapu testowania — wręcz przeciwnie: ten sam zespół programistów może dostarczać blisko dwa razy więcej funkcjonalności niż w przypadku rozwiązań natywnych. Rozwiązaniem problemu, które większości przychodzi do głowy jest magiczne słowo: automatyzacja!

I jest to rozwiązanie, które może przynieść wiele korzyści, pod warunkiem że jest wprowadzane z głową i na rozsądnym etapie pracy z projektem.

Appium

Planując automatyzację testów aplikacji mobilnych, prawdopodobnie, chcielibyśmy móc skorzystać z rozwiązania, które — podobnie jak w przypadku programistów — pozwalałoby nam na napisanie jednego kodu testów i uruchamianie ich na obu platformach bez (lub z minimalnymi) zmianami.

To było głównym kryterium, którym kierowaliśmy się przy planowaniu automatyzacji testów aplikacji tworzonych w Acaisoft, kolejnym bardzo ważnym czynnikiem była możliwość odpalania testów zarówno na symulatorach/emulatorach, jak i urządzeniach fizycznych oraz łatwa integracja z platformami udostępniającymi przeprowadzania testów w chmurze.

Działanie Appium można porównać do Selenium (na którym jest oparte). Klient — w jednym ze wspieranych języków — komunikuje się z serwerem, a ten z urządzeniem, na którym uruchamiane są testy:

Rys 2. Architektura Appium

Instalacja

Appium można zainstalować w dwóch wersjach: Serwer i Desktop, wersja Desktop, dodatkowo zawiera graficzny interface, pozwalający na inspekcję elementów aplikacji. Pakiety instalacyjne są dostępne na stronie projektu, możliwa jest również instalacja przez npm.

Testy

Testy E2E aplikacji mobilnych, tworzonych w oparciu o Appium przypominają testy tworzone w Selenium, ich implementację warto oprzeć o Page Object Pattern (czy w tym przypadku Screen Object Pattern), w oddzielnych klasach definiując ich lokatory i akcje. Jako przykład, możemy wyobrazić sobie aplikację czatów, która posiada tylko trzy widoki:

– listę czatów,
– okienko czatów,
– widok logowania.

Pliki klas mogłyby wyglądać następująco:

  • Ekran logowania:

  • Ekran listy czatów (podobny do listy czatów znanej chociażby z aplikacji Messenger)

  • ekran czatu:

Jak widać, wszystkie klasy dziedziczą po klasie ApplicationScreen – w niej można zawrzeć wszystkie uniwersalne zachowania oraz wrappery, np. własną metodę wyszukującą elementy, zawierającą oczekiwanie na widoczność elementu:

Pomiędzy klasami odpowiadającymi poszczególnym widokom a kodem testów można wprowadzić jeszcze jedną warstwę abstrakcji w której zdefiniowane są częściej używane aktywności — dzięki temu kod testów będzie czytelniejszy, a ich utrzymanie łatwiejsze:

Struktura projektu może wtedy wyglądać następująco.

Dzięki temu, kod testów może być bardzo prosty i czytelny, np. test sprawdzający, czy po otwarciu czatu z użytkownikiem John Smith widzimy odpowiednie dane rozmówcy będzie wyglądał następująco:

Przygotowanie

Do stworzenia klas odpowiadającym poszczególnym ekranom naszej aplikacji, potrzebujemy lokatorów, które pozwolą Appium na rozpoznanie elementów interface’u i wejście z nimi w interakcje. Przydatnym narzędziem będzie Appium Desktop. Po jego uruchomieniu definiujemy parametry sesji z urządzeniem, na którym jest zainstalowana nasza aplikacja i, korzystając z narzędzia inspektor możemy podejrzeć wszystkie elementy naszej aplikacji.

Appium pozwala na korzystanie ze wszystkich strategii lokatorów, znanych z Selenium, jednak w przypadku aplikacji pisanych w React Native nie będą one pomocne, de facto (jeżeli chcemy mieć uniwersalne lokatory, niezależne od platformy), musimy korzystać z jednej z dwóch strategii:

1. XPATH, odnosząca się do tekstu elementu (i nie zagnieżdżone w roocie dokumentu) np. //*[@text=”Element’s Text”] lub //*[contains(@text, “Element’s Text”)]

2. ACCESIBILITY_ID, to lokatory odnoszące się do identyfikatorów elementów, ułatwiających korzystanie z aplikacji przez osoby o np. ograniczonym widzeniu.

Korzystanie z ACCESIBILITY_ID, wymaga odpowiedniego przygotowania aplikacji przez zespół programistyczny, jednak pozwala na zlokalizowanie wszystkich typów elementów interface’u aplikacji.

Rys. 3 Inspektor Appium Desktop

Uruchamianie

Przed uruchomieniem testów, uruchamiamy serwer Appium, z którym będziemy się łączyć (czynność tę można oczywiście oskryptować wewnątrz kodu testów, zwłaszcza jeżeli chcemy dynamicznie tworzyć kolejne instancje serwera — chociażby chcąc uruchamiać testy równolegle). Połączenie z serwerem Appium inaugurujemy w kodzie testów, podobnie jak ma to miejsce w przypadku testów Selenium. Z tą różnicą, że inaugurując połączenie musimy podać parametry sesji (Desired Capabilities) — podobnie jak w przypadku łączenia się z desktopową wersją Appium. W Desired Capabilities deklarujemy, na jakiej platformie chcemy uruchamiać testy, na jakim urządzeniu oraz podajemy ścieżkę do pliku aplikacji (*.ipa lub *.apk) — ścieżka ta może mieć także postać URL:

Podsumowanie

Appium nie jest narzędziem idealnym, testy wykonywane przy jego użyciu trwają dłużej niż testy przygotowywane w natywnych rozwiązaniach. Jego niewątpliwą zaletą jest możliwość przygotowania jednego kodu testów zarówno dla iOS i Androida — co pozwala na „nadgonienie” przyspieszenia pracy programistów. Jest ono również dobrym wyborem w przypadku, kiedy w zespole znajdują się automatycy posiadający doświadczenie w Selenium — różnice są naprawdę niewielkie (ale mogą dotyczyć bardzo frustrujących aspektów — takich jak kwestia widoczności elementów, która może być inaczej interpretowana na iOS i Androidzie).

Wraz z rosnącą popularnością React Native, na rynku pojawiają się również rozwiązania dedykowane do automatyzacji testów E2E aplikacji napisanych w tym frameworku, jednak, nawet najbardziej zaawansowane — takie jak Detox — nie pozwalają jeszcze na tak szerokie zastosowania jak Appium.


 

Zapraszamy do dyskusji
Nie ma więcej wpisów

Send this to a friend