Testy w starej aplikacji mobilnej — od czego zacząć, gdy nie ma żadnych

W większości aplikacji, które przejmujemy, nie ma testów. Albo nie było ich nigdy, albo jest kilka napisanych na początku projektu, które od dawna się nie kompilują. Dopóki aplikacja nie jest zmieniana, nikt tego nie odczuwa. Problem zaczyna się przy pierwszej aktualizacji: podniesienie targetSdk, nowa wersja frameworka albo wymiana biblioteki płatności zmienia rzeczy, których nikt nie planował ruszać, i nie ma jak sprawdzić, czy wszystko działa jak wcześniej.

Ten tekst nie jest o tym, jak osiągnąć 80% pokrycia kodu. Jest o tym, jak przy rozsądnym koszcie dojść do sytuacji, w której wydanie nowej wersji przestaje być loterią.

Po co testy w aplikacji, którą tylko utrzymujesz

Utrzymanie aplikacji to w dużej części zmiany, o których nie decydujesz: wymagania sklepów, nowe wersje systemów, wycofywane SDK. Każda taka zmiana może zepsuć coś daleko od miejsca, którego dotyczy. Aktualizacja biblioteki sieciowej potrafi zepsuć logowanie, a podniesienie targetSdk — powiadomienia.

Bez testów zostają dwie możliwości. Albo ktoś przed każdym wydaniem ręcznie przeklikuje aplikację, co jest drogie i zawodne, albo sprawdzają ją użytkownicy, co widać potem w ocenach w sklepie.

Nie zaczynaj od pokrycia kodu

Procent pokrycia to wygodna liczba, ale w starej aplikacji prowadzi w złą stronę. Najłatwiej pokryć testami proste klasy pomocnicze, które rzadko się psują, a najtrudniej to, co psuje się najczęściej: ekrany, integracje i ścieżki przechodzące przez kilka modułów.

Lepszy punkt startowy to pytanie: co kosztuje najwięcej, gdy przestanie działać? Zwykle są to:

• rejestracja i logowanie, także przez Google i Apple,
• płatności i subskrypcje,
• główna ścieżka, dla której użytkownicy instalują aplikację, np. złożenie zamówienia albo rezerwacja,
• powiadomienia push,
• pierwsze uruchomienie po instalacji i po aktualizacji z poprzedniej wersji.

To kilka ścieżek, nie kilkaset. Od nich zaczynasz.

Krok 1: lista kontrolna przed wydaniem

Najtańszy początek nie wymaga pisania kodu. To spisana lista kroków, które ktoś wykonuje na prawdziwym telefonie przed każdym wydaniem:

Spisanie takiej listy zajmuje kilka godzin, a jej przejście na Androidzie i iOS — od kilkunastu minut do godziny przed każdym wydaniem. Najczęściej pomijany wiersz to aktualizacja z poprzedniej wersji, choć to właśnie ją przechodzi każdy obecny użytkownik.

Krok 2: darmowe narzędzia, które już masz

• Raport przedpremierowy w Google Play (pre-launch report). Po wgraniu wersji na ścieżkę testową Google automatycznie uruchamia ją na fizycznych urządzeniach, przeklikuje i zgłasza awarie, problemy z wydajnością i dostępnością. Jest bezpłatny i włącza się sam, ale bardzo rzadko ktoś do niego zagląda. Jeśli aplikacja wymaga logowania, w ustawieniach raportu można podać dane konta testowego.
• Testy wewnętrzne w Google Play i TestFlight. Wersję wydaną na ścieżkę testów wewnętrznych w Google Play i do TestFlight w App Store Connect może przed premierą sprawdzić zespół i kilka zaufanych osób. Dla szerszej grupy TestFlight pozwala dodać do 10 000 testerów zewnętrznych.
• Monitoring awarii. Crashlytics albo Sentry nie zastąpią testów, ale przy stopniowym wydawaniu pokażą problem, zanim trafi do wszystkich. Opisujemy to w tekście o monitoringu awarii aplikacji.

Krok 3: automatyczne testy kluczowych ścieżek

Gdy lista kontrolna jest stabilna, jej najważniejsze punkty warto zautomatyzować testami UI, które uruchamiają aplikację na emulatorze i przechodzą ścieżkę tak jak użytkownik. Narzędzia zależą od technologii:

• Maestro — scenariusze w prostym formacie YAML, działa z aplikacjami natywnymi, Flutterem i React Native. Dla starszych aplikacji bez testów to często najszybszy start, bo nie wymaga zmian w kodzie aplikacji.
• Espresso i XCUITest — natywne narzędzia Androida i iOS, dają większą kontrolę, ale wymagają więcej pracy.
• integration_test we Flutterze i Detox w React Native.

Kilka praktycznych zasad:

• Pięć do dziesięciu scenariuszy wystarczy na początek. Każdy kolejny to koszt utrzymania przy zmianach interfejsu.
• Testy potrzebują środowiska testowego. Osobny backend albo przynajmniej konta testowe i płatności w trybie sandbox. Testy na produkcji kończą się prawdziwymi zamówieniami i prawdziwymi powiadomieniami.
• Niestabilny test jest gorszy niż brak testu. Jeśli test raz przechodzi, a raz nie, zespół szybko przestaje zwracać uwagę na wynik. Takie testy trzeba naprawić albo usunąć od razu.

Krok 4: testy przy każdej zmianie

Testów jednostkowych nie trzeba pisać dla całej aplikacji naraz. Wystarczy zasada: zanim zmienisz moduł, zapisz w testach, jak działa teraz. Takie testy charakteryzacyjne utrwalają obecne zachowanie, łącznie z jego dziwactwami, i pokazują, jeśli zmiana przypadkiem je naruszy.

Najwięcej dają w logice, która nie zależy od ekranu: wyliczaniu cen i rabatów, walidacji formularzy, obsłudze dat i stref czasowych, mapowaniu odpowiedzi z API. W ten sposób testy przybywają tam, gdzie aplikacja faktycznie się zmienia. Szerzej piszemy o tym w tekście o rozbudowie istniejącej aplikacji.

Na czym testować

Nie potrzebujesz pięćdziesięciu telefonów. Wystarczy kilka konfiguracji wybranych na podstawie danych o użytkownikach:

• najstarsza wspierana wersja systemu — tu najczęściej psują się nowe biblioteki,
• najnowsza wersja systemu — tu wychodzą zmiany w zachowaniu, o których piszemy w tekście o tym, dlaczego aplikacja nie działa na nowym Androidzie lub iOS,
• mały ekran i duży rozmiar czcionki — tu rozjeżdża się układ,
• popularny tani Android — tu widać problemy z wydajnością i pamięcią.

Resztę pokryją emulatory w CI, raport przedpremierowy i chmurowe farmy urządzeń, np. Firebase Test Lab.

Testy w procesie wydawniczym

Testy, które trzeba pamiętać, żeby uruchomić, przestają być uruchamiane. Najlepiej, żeby automatyczne testy uruchamiały się przy każdej zmianie w repozytorium, a wydanie było możliwe tylko wtedy, gdy przechodzą. Jak to ustawić i ile kosztuje, opisujemy w tekście o automatyzacji wydań przez CI/CD i fastlane.

Ile to kosztuje

Orientacyjnie, przy aplikacji średniej wielkości na obie platformy:

Przy przykładowej stawce 180 zł netto za godzinę (realne stawki na rynku się różnią) pełny zestaw to ok. 9–20 tys. zł jednorazowo. Dla porównania: jedno wydanie z zepsutymi płatnościami, które trafi do wszystkich użytkowników na kilka dni, zwykle kosztuje więcej, a do tego zostawia ślad w ocenach.

Czego nie robić

• Nie wstrzymuj prac na kilka miesięcy, „żeby najpierw napisać testy". Testy mają powstawać razem z utrzymaniem, nie zamiast niego.
• Nie ustawiaj progu pokrycia kodu jako celu. Zespół zacznie pisać testy, które podnoszą liczbę, a nie bezpieczeństwo wydań.
• Nie testuj na produkcyjnym backendzie ani na prawdziwych kontach klientów.
• Nie ignoruj niestabilnych testów. Jeden niestabilny test uczy zespół, że czerwony wynik można zignorować.

Podsumowanie

Stara aplikacja bez testów nie potrzebuje wielkiego projektu testowego. Wystarczy zacząć od listy kontrolnej przed wydaniem, korzystać z darmowych narzędzi sklepów, zautomatyzować kilka najważniejszych ścieżek i dopisywać testy przy każdej zmianie. Po kilku miesiącach aktualizacje przestają być ryzykowne, a koszt każdego wydania wyraźnie spada.

Testy kluczowych ścieżek i lista kontrolna przed wydaniem to standard w aplikacjach, które prowadzimy w ramach utrzymania aplikacji mobilnych. Jeśli chcesz wiedzieć, jak wygląda proces wydawniczy Twojej aplikacji i od czego zacząć, zamów bezpłatną analizę aplikacji — wynik dostaniesz na piśmie.