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żą appWaitActivity i appWaitPackage, 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.