Appium – przed testami

Zanim zaczniemy pisać pierwsze przypadki testowe, powinniśmy odpalić serwer Appium i dowiedzieć się, jak przy jego użyciu lokalizować elementy interfejsu użytkownika testowanej aplikacji.

UI

Odpalanie serwera Appium z poziomu aplikacji desktopowej jest dziecinnie proste:

Otwieramy okno, klikamy na start serwer i już 🙂 Opcjonalnie można podać adres serwera i numer portu. Te dwie dane dane przydadzą się przy definiowaniu parametrów połączenia pythonowego klienta z serwerem.

CMD

Jeżeli zdecydowaliśmy się na instalację samego serwera Appium, bez GUI, do jego uruchomenia wystarczy wpisać w konsoli:
appium
Jeżeli instalacja przebiegła poprawnie, powinniśmy zobaczyć informację o uruchomieniu serwera.

Listę parametrów, które można podać przy uruchamianiu serwera można znaleźć pod tym linkiem: klik.

EMULATOR

Po odpaleniu serwera potrzebujemy jeszcze uruchomionego emulatora lub urządzenia w trybie debugowania. Emulator można uruchomić korzystając z Android Studio lub z poziomu linii komend,

Do odpalenia emulatora również można skorzystać z linii komend:
Windows:

CD $ANDROID_EMULATOR
./emulator -avd p2api25
CD %ANDROID_EMULATOR%
emulator -avd p2api25

 

Gdzie %ANDROID_EMULATOR% /$ANDROID_EMULATOR to zdefiniowana przez użytkownika zmienna środowiskowa zawierająca ścieżkę do katalogu, w którym znajduje się aplikacja emulator.exe.

Oczywiście, żeby emulator się odpalił, należy go wcześniej stworzyć w Android Studio (Tools->AVD Manager), lub wpisując odpowiednią komendę (to wystarczy zrobić raz).

Odpalanie emulatora z poziomu linii komend jest wygodne, bo: a) jest szybsze b) nie wymaga odpalania Android Studio 🙂

INSPEKTOR

Jednym z pierwszych narzędzi serwera Appium, z których będziemy korzystać jest Inspektor, pozwalający na podejrzenie elementów UI aplikacji i zdefiniowanie lokatorów dla poszczególnych widoków. Odpalanie inspektora przebiega następująco:

Klikamy na ikonę lupy, podajemy parametry sesji:

Inicjowana sesja uruchamiana jest ze zdefiniowanymi przez nas w zakładce Desired Capabilities, do najważniejszych należą:

  • platformName – określa w jakim środowisku będziemy pracować;
  • app – ścieżka do pliku instalacyjnego aplikacji, którą chcemy zainstalować i uruchomić;
  • deviceName – nazwa urządzenia/emulatora;
  • automationName – nazwa silnika automatyzacji.

Wszystkie parametry, w zależności od środowiska wymienione są na tej stronie: klik.

Do bardziej przydatnych parametrów należą appWaitActivityappWaitPackage, pozwalają nam one odczekać z uruchamianiem testów aż załaduje się konkretny widok lub pakiet (niestety są dostępne tylko dla Androida).

Ustawione przez nas parametry sesji warto zapisać – nie będzie potrzeby wpisywania  ich za każdym razem. 🙂  Po kliknięciu Start Session, naszym oczom (po chwili) ukazuje się widok inspektora. Możemy na nim podejrzeć, jak wygląda XML odzwierciedlający układ interesującego nas widoku. Przykładowo, tak wygląda widok aplikacji kalkulator:

Na emulatorze możemy wykonywać dowolne operacje w aplikacji, a kiedy chcemy odświeżyć podgląd widoku, klikamy na przycisk Refresh nad sekcją App Source.  W interakcje z elementami możemy wchodzić również z poziomu Inspektora, służą do tego przyciski Tap, Send Keys i Clear w prawym górnym rogu, ale mi osobiście wygodniej klikać po aplikacji w oknie emulatora.

LOKALIZOWANIE ELEMENTÓW

Do lokalizowania elementów możemy wykorzystywać (podobnie jak w Selenium) Klasy, Id, XPath, to co odróżnia  selektory Appium i Selenium to selektory przeznaczone dla aplikacji mobilnych: UIAutomatorSelector, Predicate String, Class Chain i Accesibility ID. Wybór odpowiedniego selektora wynika przede wszystkim z technologii, w jakiej tworzona jest aplikacja, w dalszej kolejności (jeżeli pozostaje nam więcej niż jedna opcja) możemy wziąć pod uwagę naszą wygodę. W mojej pracy jestem ograniczony do dwóch opcji: Accesibility ID oraz XPath. Wynika to z faktu, że aplikacje, których testowaniem się zajmuję powstają w React Native, który nie pozwala na zbyt dużą kontrolę nad końcową strukturą widoków aplikacji.

Mimo, że w tworzeniu selektorów dla aplikacji webowych korzystam najchętniej z XPath, w przypadku aplikacji mobilnych musiałem z nich zrezygnować: selektory takie okazały się być skomplikowane, długie oraz – co najważniejsze – nie były reużywalne.

W efekcie, na co dzień korzystam z Accesibility ID. Ich funkcjonowanie w testach automatycznych jest niejako skutkiem ubocznym – Accesibility ID to bowiem nic innego niż dodatkowe informacje o elementach widoku aplikacji, które są wykorzystywane przez osoby niewidome/niedowidzące. Ich zawartość jest odczytywana na głos przez oprogramowanie umożliwiające korzystanie z telefonu przez osoby z upośledzeniami widzenia. Z tego też powodu, jeżeli deweloperzy pójdą Wam na rękę i dodadzą te parametry – trzeba pamiętać o tym, aby były sensowne!

Stworzone przez nas lokatory możemy przetestować, zanim zastosujemy je w kodzie testów, służy do wyszukiwarka (dostępna po kliknięciu na lupę). Wybieramy typ lokatora wpisujemy i – jeżeli stworzyliśmy go poprawnie – powinniśmy znaleźć tylko te elementy (lub ten element), który nas interesuje.

Umiejętność lokalizowania elementów jest jedną z najważniejszych umiejętności potrzebnych do pisania automatycznych testów, bo jak mielibyśmy klikać elementy lub wpisywać w nie cokolwiek, jeżeli nie umielibyśmy przekazać komputerowi, o jaki element nam chodzi? 🙂

Więcej o lokatorach można przeczytać pod tym adresem: klik.

 

Komentarze