Testy UI na iOS

0

poprzednim tekście opisałem wyzwania i narzędzia służące do testów jednostkowych przy pisaniu aplikacji na platformę iOS. Zgodnie z obietnicą w tej części opiszę zagadnienie testów UI, czyli interfejsu aplikacji.

Temat ten jest moim zdaniem znacznie ciekawszy, głównie z uwagi na to, że rzadziej poruszany, ale także stosowane rozwiązania są jakby… bardziej graficzne. Oglądanie aplikacji, po której w zawrotnym tempie klika automat, jest dziwnie satysfakcjonujące. :-)

Wyzwania

Testy UI są z definicji testami integracyjnymi, nie skupiamy się bowiem na małych fragmentach kodu, ale na aplikacji jako całości. Sprawdzamy, jak części naszego kodu współpracują nie tylko ze sobą, ale także z zewnętrznymi bibliotekami, przede wszystkim do obsługi interfejsu graficznego.

Rodzi to niestety wiele problemów i wymaga stosowania specjalnych narzędzi – opiszę najpowszechniejsze z nich.

Testy białej czy czarnej skrzynki?

Pierwsze pytanie, jakie powinniśmy sobie zadać, to: jaki typ testów preferujemy? Z dostępem do kodu aplikacji czy bez niego? W przypadku testów UI różnica polega na tym, czy mamy dostęp do tzw. backdoorów, czyli możliwości wykonania kodu z poziomu skryptów testowych.

Istotnie wpływa to na sposób, w jaki będziemy pisać nasze testy. Jeśli nie mamy dostępu do kodu, możemy napotkać duże problemy w testowaniu niektórych funkcjonalności, ale z drugiej strony takie testy dużo lepiej oddają rzeczywiste interakcje z aplikacją.

Jak nawigować po aplikacji?

No właśnie – jak? Aplikacje na iOS są obsługiwane niemalże wyłącznie przez interakcje z ekranem dotykowym, ale raczej nie chcemy za każdym razem podawać współrzędnych dotknięcia (co z różnymi rozmiarami wyświetlacza? Co, jeśli elementy nie będą na ekranie zawsze w tych samych miejscach?). Jeszcze większy problem sprawiłoby odczytywanie wyświetlanej zawartości. Na myśl przychodzi mi jakieś rozwiązanie OCR, ale to by była katorga, więc lepiej przejdźmy do sedna.

Na iOS istnieje bardzo rozbudowane Switch Control). I właśnie ten mechanizm możemy wykorzystać na nasze potrzeby. Oczywiście nie ma sensu robić tego bezpośrednio, lepiej użyć odpowiednich bibliotek.
Mała dygresja: nie zapominajmy o mechanizmach dostępności podczas programowania, ponieważ korzysta z nich więcej osób, niż może się wydawać. Dla przykładu statystyka, która podaje, że aż 40% użytkowników korzysta z niestandardowego rozmiaru czcionki!

Jeśli używamy mechanizmu dostępności, to siłą rzeczy trzeba dostosować naszą aplikację np. do wspomnianego czytnika ekranu. Z jednej strony wymaga to od nas dodatkowej pracy, z drugiej strony przygotowanie testowalnego kodu również wymaga pracy, a nie niesie za sobą wartości dodanej w postaci umożliwienia korzystania z naszej aplikacji osobom niepełnosprawnym.

Mockowanie

Mockowanie jest niestety trudniejsze niż w przypadku testów jednostkowych. Jeśli mamy dostęp do backdoorów, może ono być bardzo podobne, choć z pewnością będzie trzeba zrobić zaślepkę dużo większych rozmiarów.

Gdy jesteśmy ograniczeni tylko do zewnętrznych interakcji z aplikacją, musimy posiłkować się innymi sposobami, takimi jak np. serwery proxy modyfikujące odpowiedzi HTTP.

Wybór odpowiedniego frameworka

Sporym wyzwaniem jest też wybór właściwego frameworka do testów UI. Standardowy dostarczany z Xcode XCUITest jest prosty w obsłudze, ale oferuje też dość małe możliwości, jest powolny i praktycznie nie pozwala na dostęp do kodu aplikacji.

Aby wybrać najlepsze rozwiązanie, musimy odpowiedzieć sobie na kilka pytań: Testy będą pisać programiści czy testerzy? Czy chcemy, aby scenariusze testowe mogły być przenoszone pomiędzy platformami? Chcemy je wykonywać tylko na symulatorze czy również na prawdziwych urządzeniach? A może mają być wykonywane w chmurze na całej farmie urządzeń?

Z uwagi na wiele czynników nie da się odpowiedzieć jednoznacznie, który framework jest najlepszy. Istnieje duża szansa, że żaden dostępny nie będzie spełniał wszystkich oczekiwań. Z jednej strony jest to oczywiście problem, ale z drugiej… Może komuś brakuje pomysłu na projekt open source? ;-)

Narzędzia

Jestem programistą, więc skupię się na najlepszych rozwiązaniach z mojej perspektywy – z pewnością nie będą one jednak najlepsze dla każdego. Jeśli chcesz się podzielić swoim zdaniem na ten temat, zapraszam do komentowania!

XCUITest

Już po nazwie można rozpoznać, że jest to framework dostarczany przez Apple.

Tak jak wspomniałem kilka akapitów wyżej – jest on powolny i nie pozwala na łatwy dostęp do kodu aplikacji. Może się wydawać, że będzie stabilny i rozbudowany, ale niestety tak nie jest. Podczas użytkowania zdarzają się pewne problemy z synchronizacją (framework nie czeka, aż aplikacja skończy wykonywać jakieś zadania w tle). Nie ma też możliwości wykonania skomplikowanych gestów ani zastąpienia ich backdoorem. XCUITest jest też zamknięty, przez co nie da się łatwo rozszerzyć jego funkcjonalności. Wykonanie własnych skryptów podczas testów nie jest łatwe, co w połączeniu z brakiem backdoorów jest dla wielu czynnikiem decydującym o porzuceniu tego rozwiązania.

Framework ten ma jednak też sporo zalet. Stworzenie pierwszego testu przy jego użyciu jest bajecznie proste. W rzeczywistości nie trzeba napisać nawet linijki kodu, ponieważ ten pisze się sam w trybie nagrywania. Oczywiście nie jest to metoda, która się sprawdzi na dłuższą metę, ale może przyspieszyć integrację tego frameworka. XCUITest dobrze integruje się z systemem i np. pomijanie systemowych powiadomień (choćby zezwolenia na usługi lokalizacyjne) jest automatyczne. Wszystkie jego funkcje działają na urządzeniu równie dobrze co na symulatorze.

EarlGrey

Ten framework dostarczany przez Google jest – z tego, co słyszałem – bardzo podobny do Espresso na Androidzie. Z tego drugiego niestety nie korzystałem, więc proszę, poprawcie mnie, jeśli się mylę.
Zdradzę od razu, że jest to mój wybór – jeśli jesteście programistami iOS chcącymi dodać testy UI do swojej aplikacji, możecie zapisać sobie tę nazwę i nie czytać dalej. ;-) EarlGrey jest bardzo szybki, choć nie aż tak szybki jak KIF. Ma za to zaawansowany mechanizm synchronizacji, co czyni go bardzo stabilnym. Charakteryzuje się dużymi możliwościami interakcji z aplikacją, pozwala na pisanie własnych rozszerzeń, a gdy napotka błąd, drukuje w konsoli bardzo dużo informacji, co często pozwala na znalezienie jego przyczyny na podstawie tylko tych danych.

Ma też wady w postaci np. problemu z pomijaniem systemowych alertów, ale lada dzień ma wyjść wersja 2.0, która powinna naprawić tę usterkę. Wydanie jej miało nastąpić co prawda już pół roku temu, ale według najnowszych wiadomości z ich Slacka (do którego warto dołączyć) jest ona obecnie w ostatniej fazie akceptacji.

KIF

Do czasu powstania EarlGrey KIF był najlepszym rozwiązaniem do testów UI na iOS. Nie uważam, żeby obecnie był sens stosowania go w nowych projektach, ale jeśli ktoś potrzebuje np. małego zestawu superszybkich testów, to nadal może skorzystać z tego frameworka.

Jest bardzo podobny do EarlGrey (choć według mnie trochę gorszy w różnych mniejszych kwestiach) i – co ważne – nie posiada synchronizacji. Oznacza to, że śmiga po interfejsie aplikacji szybciej niż cokolwiek innego, ale jeśli nasz kod nie jest doskonały lub dużo dzieje się w tle, to KIF będzie się czasem zawieszał lub wywalał. Nie jest też rozwijany tak dynamicznie jak EarlGrey.

Inne

Istnieje jeszcze kilka innych frameworków do testowania UI. Każdy czytający to tester pewnie pomyśli, że zapomniałem o Appium lub Calabashu. Choć z tym drugim miałem nawet sporo do czynienia, to nie jestem ich fanem.

Ich wspólnymi cechami są multiplatformowość, powolność i duże wymagania co do czasu implementacji. Niestety dostępność na wielu platformach często nie idzie w parze ze zmniejszeniem czasu implementacji, ponieważ z uwagi na różnice między platformami trzeba poświęcać dużo czasu na debugowanie testów. W dodatku frameworki te wymagają nie tylko znajomości jednej platformy, ale często też drugiej (lub współpracy z inną osobą) oraz dodatkowo Ruby, Basha, JS i Gherkina. Z mojego doświadczenia wynika, że lepszym rozwiązaniem są szybkie natywne testy na każdej platformie i synchronizowanie ich zawartości wedle potrzeb.

Bonus

Pisanie testów UI ma jeszcze jedną zaletę – bardzo ułatwia tworzenie zrzutów ekranu aplikacji do publikacji w App Store. Przy użyciu fastlane snapshot dzieje się to niemal magicznie. 10 zrzutów pomnożone przez 7 rozmiarów oraz 28 języków to sumarycznie 1960 obrazków. Z pewnością nie chcecie robić tego ręcznie nawet raz, a co dopiero przy każdej aktualizacji!

Podsumowanie

Testy UI to bardzo rozległy temat, więc nie da się wszystkiego opisać w tak krótkiej formie. Mimo to mam nadzieję, że ten tekst wam się przydał i przybliżył trochę tematykę testowania UI na iOS. Jeśli macie propozycje kolejnych tematów, zapraszam zostawiania komentarzy. Prędzej czy później na wszystkie odpowiem!

A teraz…

Zobacz poprzednie teksty!

Nie przegap kolejnych postów!

Dołącz do ponad 9000 programistów w devstyle newsletter!

Tym samym wyrażasz zgodę na otrzymanie informacji marketingowych z devstyle.pl (doh...). Powered by ConvertKit
Share.

About Author

Programista iOS w intive, prelegent, mentor, bloger. Nie cierpi oprogramowania niskiej jakości. Ważniejsze niż odgadnięcie czemu coś się psuje jest zrozumienie dlaczego działa. Więcej na mojej stronie oraz Medium.

Comments are closed.