Jak testujemy aplikacje Android?

Testy jednostkowe w szeroko pojętej inżynierii oprogramowania już dość dawno, w zdecydowanej większości technologii, były czymś dość oczywistym. Często stosowane, głośno promowane, przeżywającego swego rodzaju hype.

Mam jednak wrażenie, że w świecie Androida testowanie jednostkowe jakby opóźniło się względem innych i bywa czasami traktowane po macoszemu. Testy pisane bez większego zastanowienia lub całkowicie pomijane – zarówno ze względu na brak wiedzy, jak i chęci ze strony deweloperów.

Chciałem sprawdzić jak rzeczywiście się miewa ten aspekt w obecnych projektach – stworzyłem ankietę, mającą na celu zebranie informacji od Android Developerów na temat tego, jak w ich projektach wygląda sytuacja z testowaniem.

Wyniki ankiety

W ciągu około tygodnia na moją ankietę odpowiedziało 58 osób. Udało mi się dotrzeć do nich za pomocą kręgu swoich znajomych, Twittera, LinkedIn czy Facebooka. Ankieta zawierała pytania o praktyki i narzędzia używane przy testowaniu, o samego dewelopera, jak i projekt, w którym uczestniczy, aby łatwiej było później w razie potrzeb te dane pogrupować.

Jestem bardzo miło zaskoczony czasem dostępnym na pisanie testów. Aż 49% ankietowanych stwierdziło, że ma wystarczająco dużo czasu na pisanie testów jednostkowych. Blisko 37% twierdzi, że ma czas na testy, ale niewystarczająco dużo. Natomiast tylko 14% nie ma tego czasu w ogóle. Przyznaję, że spodziewałem się gorszych wyników.

Zdziwiło mnie natomiast podejście ankietowych do samych testów. Lekko ponad 67% czuje chęć i potrzebę pisania testów. Nie jest to mało, ale spodziewałem się tutaj dużo wyższego wyniku i świadomości deweloperów o potrzebie posiadania takich testów w projekcie. Niespełna 14% twierdzi, że nie ma na to najmniejszej ochoty. Jest też grupa (19%), w której jest jeszcze nadzieja, że przejdą na stronę chętnych, obecnie jest im to obojętne.

Poza czasem i chęcią na pisanie testów, ważne też jest, jak deweloperzy oceniają swoje umiejętności w tym zakresie. Wygląda na to, że pomimo dobrych wyników w kwestii czasu na pisanie testów oraz wielu chętnych do realizacji tego zadania, umiejętności (lub samoocena ;) ) ankietowanych wypadają już gorzej. Tylko 26% procent twierdzi, że potrafi pisać testy i wychodzi im to bardzo dobrze! Biorąc pod uwagę, że 38% ankietowanych to seniorzy, a 45% regular, wynik ten wydaje się dość słaby. Niespełna 45% potrafi pisać testy, ale odczuwa pewne braki, 24% potrafi pisać proste testy, ale uważają, że przed nimi jeszcze dużo nauki w tej kwestii. Tylko 5% nie potrafi pisać testów w ogóle. Ten ostatni wynik jest dla mnie najbardziej pocieszający!

Co testujemy?

Jednym z najważniejszych dla mnie pytań było co dokładnie w aplikacjach Androidowych jest testowane. Nie zdziwiło mnie, że najwyższe miejsca zajmowały metody narzędziowe (utils) na równi z logiką biznesową (ale w wariancie “tylko najważniejsze klasy i metody”). Obie te opcje zadeklarowało ponad 53%.
Moim pozytywnym zaskoczeniem jest drugie miejsce, które zajęło testowanie integracji z REST API, prawie 45% ankietowanych zadeklarowało testowanie komunikacji.
Trzecie miejsce po równo (ponad 41%) zajęły logika prezentacji (prezentery, ViewModele lub ta zaszyta we Fragmentach i Activity) oraz logika biznesowa jako całość (nie tylko najważniejsze klasy i metody).

W kontekście testowania na poziomie komponentów Androidowych (Activity, Service, Broadcast Receiver, Content Provider) cieszy testowanie usług (Service) - ponad 22% deklaruje, że są one testowane. Activity testuje tylko 12%. Nie dziwi mnie wynik BroadcastReceiverów ze względu na ich raczej dość proste działanie oraz Content Providerów – są bardzo rzadko implementowane.

Czym testujemy?

W kwestii narzędzi bez zaskoczenia: króluje duet JUnit (93%) oraz Mockito (84%).

Pojawiały się też pojedyncze przypadki stosowania Spocka czy TestNG lub nowych frameworków dedykowanych dla języka Kotlin (Spek czy KotlinTest). Prawie 36% deklaruje użycie w testach Robolectrica, o którym na łamach devstyle będę jeszcze pisał. Miło mi widzieć dość sporą popularność MockWebServer (ponad 23%). Oznacza to, że ta część deweloperów bardzo poważnie traktuje testy integracyjne z API i gruntownie ten aspekt testuje.

Z innych przydatnych narzędzi: niecałe 27% zebrał PowerMock oraz AspectJ i Hamcrest:  po 30%.

Do brzegu!

Ankieta pokazała mi, że jest lepiej, niż się spodziewałem, ale z drugiej strony często brak jest czasu na pisanie testów czy chęci ze strony deweloperów do realizacji tego zadania. Być może niektórzy potrzebują zachęty lub zobaczenia na własne oczy, że nie jest to takie straszne? To naprawdę ma sens i wnosi wartość do projektu!

Chciałbym tym samym zaprosić Was do cyklu “Testowanie jednostkowe w Android”, który będzie pojawiał się tutaj, na łamach bloga devstyle.pl (co jest dla mnie niesamowitym wyróżnieniem !!). Tekst, który czytasz, miał na celu przedstawienie rzeczywistości testowania w projektach Android. W kolejnych będę już poruszał dużo bardziej techniczne tematy powiązane z testowaniem.

Cykl będzie składał się z co najmniej 4 tekstów. Zacznę od przedstawienia możliwości testowania na Androidzie i opowiem, z jakimi wyzwaniami to się wiąże. Opiszę podstawowe narzędzia, takie jak JUnit, Mockito czy AssertJ, ale zapoznam Cię też z Robolectriciem. Spróbuję odpowiedzieć na pytanie: kiedy jest fajny, a kiedy nie? Dodatkowo, przedstawię co najmniej jeden element, który nie jest trywialny w testowaniu, ale często pojawia się w aplikacjach.

Daj znać w komentarzu lub na Twitterze, jeżeli masz jakiś pomysł na temat, który mógłbym poruszyć w ramach tego cyklu!

Do zobaczenia przy okazji kolejnego tekstu!