Jak testować aplikację React Native w Maestro i kiedy wybrać go zamiast Detox?

Źródła sprawdzone 12 listopada 2026.

Ten poradnik jest dla osoby, która odpowiada za jakość firmowej aplikacji w React Native i chce dodać automatyczne testy E2E albo wybiera między Maestro a Detox. Opisuje przygotowanie aplikacji, pierwsze przepływy, dane testowe i uruchamianie w CI.

Odpowiedź w skrócie: Maestro pozwala szybko opisać ścieżki użytkownika bez zmian w kodzie aplikacji poza testID. Ograniczenia: dokumentacja Maestro wymienia na iOS tylko symulatory, więc nie zakładaj testów na fizycznych iPhone'ach, a narzędzie nie widzi stanu wewnątrz aplikacji. Zanim napiszesz dziesiątki testów, sprawdź na dwóch lub trzech przepływach, czy działają stabilnie w Twoim CI.

Według dokumentacji Maestro narzędzie traktuje aplikację jak czarną skrzynkę i symuluje działania użytkownika na ekranie. Testy są deklaratywne, zapisane w YAML, i uruchamiają się bez kompilacji.

Maestro samodzielnie czeka na załadowanie treści i zakończenie animacji, więc w testach nie trzeba wstawiać ręcznych pauz. Może też wychodzić poza aplikację, na przykład do ustawień systemu albo powiadomień.

Testy można pisać w edytorze albo w aplikacji Maestro Studio, która pozwala tworzyć je wizualnie na podłączonym urządzeniu.

Oba narzędzia testują aplikację React Native na urządzeniu lub symulatorze, ale różnią się podejściem. Porównanie na podstawie dokumentacji obu projektów:

Detox opisuje się jako framework testów typu gray box dla React Native: testy pisze się w JavaScript, a Detox monitoruje operacje asynchroniczne w aplikacji, aby ograniczyć niestabilność. Testy na fizycznych urządzeniach z iOS nie są w nim jeszcze obsługiwane.

Wybór zależy od zespołu i aplikacji. Maestro ułatwia start osobom, które nie piszą kodu na co dzień. Detox daje programistom testy w tym samym języku co aplikacja i ściślejszą synchronizację z jej stanem.

Maestro potrafi wskazać element po widocznym tekście, ale taki test psuje się po zmianie etykiety albo tłumaczenia.

Strona Maestro o React Native zaleca właściwość testID, którą Maestro mapuje na unikalny identyfikator elementu. W teście odwołujesz się wtedy do identyfikatora, a nie do tekstu, więc test działa także w innych wersjach językowych.

Ustal konwencję nazw (na przykład ekran_element) i dodawaj testID do przycisków, pól formularzy i elementów, które test ma sprawdzić. W Expo Go aplikację otwiera się przez link (openLink), a nie przez launchApp z własnym identyfikatorem aplikacji, dlatego do testów w CI lepiej użyć samodzielnego buildu, w którym działa zwykłe launchApp.

Przykład hipotetyczny: test logowania w aplikacji sklepu. Każdy krok to jedna komenda w pliku YAML:

Taki przepływ jest krótki, ale sprawdza kilka warstw naraz: ekran, walidację formularza, połączenie z backendem i przejście do kolejnego widoku. Dlatego dobrze nadaje się na pierwszy test w CI.

1. launchApp: uruchom aplikację.
2. tapOn z identyfikatorem pola e-mail, potem inputText z adresem konta testowego.
3. tapOn z identyfikatorem pola hasła i inputText z hasłem konta testowego.
4. tapOn z identyfikatorem przycisku logowania.
5. assertVisible z identyfikatorem elementu ekranu głównego.

Testy E2E są wolniejsze i droższe w utrzymaniu niż testy jednostkowe, więc zacznij od ścieżek, których awaria kosztuje najwięcej:

• Logowanie i rejestracja, także odzyskiwanie hasła.
• Zakup lub zamówienie: koszyk, dostawa, płatność w środowisku testowym operatora.
• Uprawnienia systemowe: zgoda na powiadomienia, lokalizację lub aparat.
• Pierwsze uruchomienie: onboarding i ekrany zgód.
• Funkcja, dla której klienci pobierają aplikację, na przykład karta lojalnościowa albo historia zamówień.

Jeśli firma ma także sklep internetowy, ścieżkę zakupu w przeglądarce warto testować osobnym narzędziem. Opisujemy to w poradniku o testach E2E sklepu w Playwright.

Niestabilne testy E2E wynikają nie tylko z narzędzia, ale też z danych. Test, który loguje się na konto z innym stanem koszyka przy każdym uruchomieniu, raz przejdzie, a raz nie.

Przygotuj osobne środowisko backendu z kontami testowymi, stałymi produktami i trybem testowym operatora płatności. Każdy test powinien zaczynać się od znanego stanu aplikacji i nie zależeć od wyniku innego testu.

Danych dostępowych nie zapisuj w plikach YAML w repozytorium. Przekazuj je jako zmienne środowiskowe z sekretów systemu CI.

Domyślne oczekiwanie Maestro wystarcza dla ekranów, które ładują się w kilka sekund. Dla dłuższych operacji dokumentacja przewiduje osobne komendy.

Według opisu komend oczekiwania w Maestro extendedWaitUntil służy do wolnych odpowiedzi sieci, na przykład przetwarzania płatności, a waitForAnimationToEnd do elementów, które są widoczne, ale jeszcze się przesuwają. Dokumentacja odradza ustawianie długiego limitu czasu dla każdego kroku, bo ukrywa to spadki wydajności.

Jeśli test raz przechodzi, a raz nie, nie zwiększaj od razu limitów czasu. Sprawdź najpierw dane testowe, animacje i to, czy test nie zależy od kolejności wykonania.

Przed wyborem infrastruktury sprawdź, gdzie Maestro może działać. Lista obsługiwanych platform Maestro podaje pełne wsparcie dla emulatorów i fizycznych urządzeń z Androidem oraz dla symulatorów iOS.

Testy na iOS w CI wymagają więc maszyny z macOS i symulatorem. Alternatywą jest chmura Maestro, do której wysyła się build aplikacji i pliki testów.

Na początek wystarczy uruchamiać kilka kluczowych przepływów przy każdej zmianie w głównej gałęzi, a pełny zestaw przed wydaniem do sklepu. Wyniki, zrzuty ekranu i nagrania z nieudanych testów zapisuj jako artefakty CI, żeby zespół mógł ocenić błąd bez ponownego uruchamiania.