Maestro - prosty sposób na automatyczne testowanie aplikacji mobilnych

Czwartek, godzina 17. Nowa wersja aplikacji czeka na wysyłkę do App Store i Google Play. Tester przeklikuje logowanie, koszyk i płatność na dwóch telefonach, bo tak wygląda każde wydanie. W poniedziałek okazuje się, że na Androidzie przestał działać przycisk „Przypomnij hasło”. Nikt go nie sprawdził, bo nie był na liście. 

Maestro to prosty sposób na automatyczne testowanie aplikacji mobilnych, który ma zdjąć z zespołu to ręczne przeklikiwanie. Test zapisuje się w nim jako listę kroków w pliku tekstowym: uruchom aplikację, stuknij „Zaloguj się”, wpisz e-mail, sprawdź, czy pojawił się ekran zamówień. Programista nie jest do tego potrzebny, choć dobrze, żeby był w pobliżu.

Co właściwie sprawdza test end-to-end w aplikacji mobilnej

Aplikację testuje się na kilku poziomach. Testy jednostkowe sprawdzają pojedyncze funkcje w kodzie, na przykład czy rabat liczy się poprawnie. Testy end-to-end (E2E) patrzą na aplikację tak jak użytkownik: uruchamiają ją na telefonie lub emulatorze, stukają w przyciski i sprawdzają, co pojawia się na ekranie. Testów E2E jest zwykle najmniej, bo są wolniejsze i droższe w utrzymaniu. Dobrze opisuje to piramida testów łącząca testy jednostkowe, integracyjne i systemowe. Za to tylko one wyłapią błąd, który powstaje na styku wielu elementów: nowa wersja biblioteki płatności zasłania przycisk, zmiana w API psuje ekran profilu, a tłumaczenie wydłuża etykietę tak, że nie mieści się na małym ekranie.

W aplikacjach mobilnych jest jeszcze jeden powód, żeby je mieć. Wydanie poprawki trwa. Sklepy sprawdzają nową wersję, użytkownicy aktualizują aplikację z opóźnieniem, a część nie robi tego wcale. Błąd, który na stronie internetowej naprawia się w godzinę, w aplikacji mobilnej potrafi zostać u klientów na tygodnie.

Dlatego przed każdym wydaniem zespoły powtarzają testy regresji, czyli sprawdzają, czy zmiany nie zepsuły tego, co wcześniej działało. Robione ręcznie zajmują godziny. Z czasem obejmują coraz mniej, bo nikt nie ma czasu przeklikać wszystkiego na dwóch systemach i kilku rozmiarach ekranu.

Maestro, czyli automatyczne testowanie aplikacji mobilnych bez pisania kodu

Maestro to narzędzie open source rozwijane od 2022 r. przez firmę mobile.dev. Kod Maestro jest dostępny na GitHubie na licencji Apache 2.0 i ma ponad 15 tys. gwiazdek, co w świecie narzędzi testowych jest dużą liczbą. Nowe wersje wychodzą mniej więcej co miesiąc.

Najważniejsza różnica wobec starszych narzędzi to sposób zapisu testów. W Maestro test nazywa się flow i jest plikiem w formacie YAML, czyli prostym tekście, w którym każda linia to jedno polecenie. Test logowania może wyglądać tak:

1. launchApp - uruchom aplikację,
2. tapOn: „Zaloguj się” - stuknij w przycisk z tym napisem,
3. inputText: „anna@firma.pl” - wpisz adres e-mail,
4. tapOn: „Dalej”,
5. assertVisible: „Twoje zamówienia” - sprawdź, czy pojawił się właściwy ekran.

Taki plik przeczyta zarówno tester, jak i właściciel produktu. Gdy test nie przechodzi, od razu widać, na którym kroku, a Maestro zapisuje zrzut ekranu z chwili błędu. Nie trzeba niczego kompilować, więc po zmianie w teście można go od razu uruchomić ponownie. Maestro nie zagląda do kodu aplikacji. Steruje telefonem tak jak człowiek, dlatego działa z aplikacjami natywnymi na Androida i iOS, a także z tymi, które powstały w React Native. Podobnie jest z aplikacjami we Flutterze, gdzie jeden kod obsługuje oba systemy. Test też może być jeden, choć przy różnicach w interfejsie część kroków trzeba rozdzielić.

Do narzędzia wiersza poleceń dochodzi Maestro Studio, czyli aplikacja na Maca i Windowsa. Pokazuje ekran telefonu, a kliknięcia zamienia w kroki testu. To dobry start dla osób, które nie pracują na co dzień w terminalu. Jest też serwer MCP, dzięki któremu asystenci AI mogą sami tworzyć i uruchamiać testy w Maestro.

Dlaczego testy mobilne tak często „migają”

Każdy, kto utrzymywał testy E2E, zna flaky tests, czyli testy, które raz przechodzą, a raz nie, choć w aplikacji nic się nie zmieniło. Przyczyną jest zwykle czas. Test stuka w przycisk, zanim ekran się załaduje, bo serwer akurat odpowiada wolniej niż zwykle. W starszych narzędziach programiści ratują się ręcznymi pauzami: „poczekaj trzy sekundy”. Na szybkim komputerze to za dużo, na wolnym serwerze CI za mało. Po kilku miesiącach test trwa kwadrans, a i tak czasem nie przechodzi. Zespół zaczyna ignorować czerwone wyniki. Wtedy testy tracą sens.

Maestro rozwiązuje to inaczej. Przed każdym krokiem sam czeka, aż ekran się ustabilizuje, a jeśli element pojawi się z opóźnieniem, próbuje ponownie przez określony czas. Ręczne pauzy są potrzebne rzadko. Nie znaczy to, że testy w Maestro nigdy nie migają, ale źródło problemu jest zwykle w aplikacji albo w danych testowych, a nie w samym narzędziu.

Stabilność zależy też od środowiska. Emulatory Androida i symulatory iOS są tańsze i szybsze w obsłudze niż fizyczne telefony, a testowanie aplikacji mobilnych na emulatorach pozwala łatwo sprawdzić różne wersje systemu i rozmiary ekranu. Do codziennych testów regresji w zupełności wystarczają.

Maestro na tle Appium, Detoxa i narzędzi natywnych

Maestro nie jest pierwszym narzędziem do automatyzacji testów mobilnych. Wybór zależy od technologii aplikacji i od tego, kto ma pisać testy.

Appium jako narzędzie do automatycznego testowania aplikacji mobilnych to standard od ponad dekady. Obsługuje wiele języków programowania i ma ogromny ekosystem, ale wymaga sporej konfiguracji, a testy pisze się jako kod. W zespołach z doświadczonymi testerami automatyzującymi nadal ma sens, zwłaszcza gdy firma ma już w nim setki testów.

Detox powstał z myślą o React Native i ma dostęp do wnętrza aplikacji: wie, kiedy skończyła ładować dane, więc sam synchronizuje kroki testu. Testy pisze się w JavaScripcie, co dla zespołu React Native jest naturalne, a dostęp do stanu aplikacji sprawia, że testy E2E w Detoxie należą do stabilnych. Poza React Native Detox się nie przyda.

Espresso na Androidzie i XCUITest na iOS to narzędzia dostarczane przez Google i Apple. Są najszybsze i mają najgłębszy dostęp do systemu, ale każde działa tylko na jednej platformie. Aplikacja na oba systemy potrzebuje więc dwóch zestawów testów pisanych przez programistów znających Kotlina i Swifta. Przy tworzeniu aplikacji natywnych i cross-platform wybór narzędzia testowego warto więc zestawić z wyborem technologii samej aplikacji.

Maestro wypada najlepiej tam, gdzie liczy się szybki start i czytelność. Wspólne testy dla Androida i iOS oraz niska bariera wejścia. Płaci się za to mniejszą kontrolą: skomplikowaną logikę testu trzeba dopisywać w JavaScripcie, a do stanu aplikacji Maestro nie ma dostępu.

Kiedy Maestro nie wystarczy

Maestro oficjalnie obsługuje na iOS tylko symulatory. Według listy wspieranych platform w dokumentacji Maestro pełne wsparcie dla fizycznych urządzeń ma wyłącznie Android. Istnieją rozwiązania społeczności, które uruchamiają Maestro na prawdziwych iPhone’ach, ale to wciąż nie jest ścieżka oficjalna. Jeśli aplikacja korzysta z Face ID, NFC, aparatu czy Bluetooth, część scenariuszy i tak trzeba sprawdzać ręcznie na telefonie. Dotyczy to zwłaszcza aplikacji, w których kluczowe procesy przechodzą przez zewnętrzne ekrany: potwierdzenie płatności w aplikacji banku albo logowanie biometrią. W aplikacjach dla finansów i fintechu takich miejsc jest dużo i zwykle kończą się one zaślepką w środowisku testowym zamiast prawdziwego procesu.

Maestro nie zastąpi też testów wizualnych, które porównują wygląd ekranów piksel po pikselu, ani testów wydajności. Sprawdzi, że przycisk „Kup teraz” jest widoczny i działa. Nie powie, że przesunął się o kilka pikseli albo że ekran ładuje się dwa razy wolniej niż w poprzedniej wersji.

Ostatnia sprawa to skala. Przy kilkuset testach z rozbudowaną logiką YAML zaczyna przypominać program napisany w języku, który do tego nie służy. Maestro pozwala dzielić testy na mniejsze, wielokrotnie używane fragmenty i dopisywać JavaScript, ale zespół, który potrzebuje pełnej kontroli, lepiej poczuje się w Appium lub narzędziach natywnych.

Ile kosztuje wdrożenie testów w Maestro

Samo narzędzie jest darmowe. Według cennika Maestro bezpłatnie można używać narzędzia wiersza poleceń, Maestro Studio i serwera MCP, uruchamiając testy lokalnie lub na własnych serwerach. Maestro Cloud, czyli farma urządzeń, na której testy uruchamiają się równolegle, kosztuje 250 USD miesięcznie za każde urządzenie działające jednocześnie. Chmura dostawcy nie jest obowiązkowa. Testy można uruchamiać w potoku CI/CD, czyli automacie, który po każdej zmianie w kodzie buduje i sprawdza aplikację.

Zespoły korzystające z usług do budowania aplikacji mobilnych, takich jak Bitrise do automatyzacji budowy i wdrożeń, mogą dodać Maestro jako kolejny krok. Płacą wtedy za minuty pracy maszyn, a testy na iOS wymagają maszyn z macOS, które są droższe od linuksowych.

W projektach opartych na Expo i usługach EAS integracja jest najprostsza. EAS Workflows ma gotowy krok do uruchamiania testów Maestro. Zbudowana aplikacja trafia prosto do testów, bez ręcznej konfiguracji emulatorów.

Większym kosztem niż narzędzie jest czas zespołu. Pierwsze kilka scenariuszy dla najważniejszych ścieżek, razem z konfiguracją w CI, to zwykle od kilku dni do dwóch tygodni pracy. Pełny zestaw testów regresji dla średniej aplikacji to kilka tygodni, rozłożonych najlepiej na kolejne sprinty. Na widełki wpływa przede wszystkim liczba ekranów i ścieżek, jakość danych testowych, to, czy elementy interfejsu mają stabilne identyfikatory, po których test może je znaleźć, oraz to, jak bardzo interfejs na Androidzie różni się od wersji na iOS.

Do tego dochodzi utrzymanie. Każda zmiana w interfejsie może wymagać poprawki testu. Przy czytelnych plikach YAML to zwykle minuty, a nie godziny, ale trzeba to wliczyć w pracę nad każdą funkcją.