Testowanie aplikacji mobilnych z agentami AI

Testowanie aplikacji mobilnych z agentami AI działa, gdy agent steruje prawdziwym symulatorem lub emulatorem, a nie tylko czyta kod źródłowy. Typowy układ to Maestro MCP jako dostęp do urządzenia, flow Maestro lub testy Detox oparte na stabilnych identyfikatorach dostępności oraz zasada, że test przyjmuje się dopiero, gdy zawiedzie na celowo zepsutym buildzie; mała macierz urządzeń jest bramką każdego pull requesta.

Twoja aplikacja React Native działa na iPhonie, który leży na biurku. Potem przychodzą raporty o crashach: starszy telefon z Androidem od producenta z własną nakładką systemową, mały iPhone, na którym przycisk płatności chowa się pod klawiaturą, i układ tabletowy z nachodzącymi na siebie etykietami. Miesiąc temu poprosiłeś agenta o „testy E2E” i dostałeś 40 zielonych testów. Żaden niczego z tego nie wyłapał. Ta strona jest dla programisty, który odpowiada za aplikację w React Native, Flutterze albo natywną, oraz dla tech leada, który decyduje, co uruchamia się przy każdym pull requeście.

Co znajdziesz w tym przewodniku

• Tabelę decyzyjną: który framework ma pisać agent — Maestro, Detox, Flutter integration_test lub Patrol, czy natywne XCUITest i Espresso
• Maestro MCP i MobileBuildMCP skonfigurowane w Claude Code, Codeksie lub Cursorze, tak aby agent sprawdzał swoją pracę na urządzeniu
• Pięć promptów do skopiowania: smoke flow Maestro, zestaw Detox z uprawnieniami, audyt kontroli negatywnej, macierz urządzeń i testy offline
• Procedurę weryfikacji, która dowodzi, że wygenerowany test łapie błędy, bez czytania każdej jego linii
• Warstwową macierz urządzeń i polecenia CI, które ją uruchamiają

Który framework testów mobilnych powinien pisać agent?

Wybierz framework, zanim napiszesz prompt. Agent poproszony o „testy mobilne” wybierze za ciebie — zwykle najbardziej znany framework, a nie ten, który pasuje do twojej aplikacji.

Framework	Najlepszy do	Co pisze agent	Ograniczenia (sprawdzone 2026-09-26)
Maestro 2.11.0	Smoke i regresja na dowolnym stosie: React Native, Flutter, natywne, hybrydowe	Płaski YAML (tapOn, assertVisible), czytelny dla QA i recenzentów	Brak obsługi fizycznych urządzeń iOS; setAirplaneMode działa tylko na Androidzie
Detox 20.51.4 (npm)	Aplikacje React Native, które potrzebują kontroli na poziomie kodu i synchronizacji z bezczynnością aplikacji	TypeScript na Jest	Tylko React Native; uprawnienia w launchApp tylko na iOS
Flutter integration_test / Patrol 4.10.0 (pub.dev)	Aplikacje Flutter; Patrol dokłada natywne dialogi i systemowy UI	Dart	Sam integration_test nie kliknie natywnego dialogu uprawnień
XCUITest / Espresso	Aplikacje natywne i przebiegi na prawdziwych urządzeniach w farmach urządzeń	Swift / Kotlin	Dwa zestawy do utrzymania; najwolniejsza iteracja dla agenta

Dla większości zespołów cross-platformowych odpowiedź brzmi: Maestro na zestaw smoke plus jeden framework na poziomie kodu dla ścieżek krytycznych. Przepływy w YAML są na tyle krótkie, że recenzent w minutę oceni, co weryfikują ich asercje — a gdy testy pisze agent, to ważniejsze niż jakakolwiek funkcja frameworka. Konfiguracja buildów dla konkretnych stosów jest w cookbooku: React Native, Flutter, Expo oraz natywne iOS i Android.

Daj agentowi urządzenie, a nie tylko kod źródłowy

Agent, który czyta wyłącznie pliki nawigacji, zgaduje selektory, czasy oczekiwania i zawartość ekranu. Agent z urządzeniem może spojrzeć na ekran. Większość pracy wykonują dwa serwery MCP:

• Maestro MCP jest wbudowany w CLI Maestro (maestro mcp, nic więcej nie trzeba instalować). Agent podgląda ekran, stuka, przewija i sprawdza asercje na emulatorze, symulatorze albo fizycznym urządzeniu z Androidem, a potem zapisuje kroki jako flow YAML. Maestro 2.5.0 usunął osiem zbędnych narzędzi i połączył narzędzia uruchamiania w jedno, więc lista narzędzi serwera pozostaje krótka (sprawdzone w Maestro 2.11.0).
• MobileBuildMCP (dawniej XcodeBuildMCP, własność Sentry, npm mobilebuildmcp 2.7.1) buduje aplikacje na iOS i macOS, uruchamia symulatory i uruchamia testy XCTest. Wymaga macOS 14.5+ i Xcode 16+.

Najpierw zainstaluj Maestro (wymaga Javy 17 lub nowszej), a potem zarejestruj serwery:

curl -fsSL "https://get.maestro.mobile.dev" | bash

Claude Code

claude mcp add maestro -- maestro mcp
claude mcp add mobilebuild -- npx -y mobilebuildmcp@latest mcp   # tylko macOS

Dodaj -s project, aby wpis trafił do .mcp.json i był dostępny dla całego zespołu.

Codex

codex mcp add maestro -- maestro mcp
codex mcp add mobilebuild -- npx -y mobilebuildmcp@latest mcp   # tylko macOS

Cursor

Dodaj oba serwery do .cursor/mcp.json w projekcie (albo do ~/.cursor/mcp.json, aby działały we wszystkich projektach). MobileBuildMCP działa tylko na macOS.

{
  "mcpServers": {
    "maestro": { "command": "maestro", "args": ["mcp"] },
    "mobilebuild": { "command": "npx", "args": ["-y", "mobilebuildmcp@latest", "mcp"] }
  }
}

Oba polecenia używają udokumentowanych poleceń startowych serwerów (maestro mcp, npx -y mobilebuildmcp@latest mcp). Po dodaniu uruchom /mcp w Claude Code albo codex mcp list, aby potwierdzić połączenie. Pełny katalog serwerów znajdziesz w artykule o serwerach MCP dla środowisk deweloperskich.

Przepływ pracy: eksploracja na urządzeniu, test, dowód, że test umie zawieść

1. Najpierw dodaj stabilne selektory. Poproś agenta o testID (React Native), identyfikatory Key lub Semantics (Flutter) albo accessibilityIdentifier / testTag (natywne) na każdym elemencie, którego dotyka flow. Testy dopasowujące widoczny tekst psują się przy pierwszej zmianie tekstów interfejsu albo tłumaczenia.

2. Pozwól agentowi przejść flow na uruchomionym urządzeniu. Z podłączonym Maestro MCP agent przechodzi przez prawdziwą aplikację i notuje, co widzi. To zastępuje zgadywanie na podstawie src/navigation/.

3. Niech napisze test i uruchamia go, aż będzie zielony. Flow lub spec trafia do repozytorium, więc staje się deterministycznym testem w CI, a nie jednorazową sesją agenta.

4. Zepsuj aplikację i patrz, jak test zawodzi. To kontrola negatywna. Test, który pozostaje zielony po usunięciu przycisku, na którym robi asercję, niczego nie chroni. Pełną metodę opisuje artykuł jak silna jest twoja wyrocznia.

5. Podłącz zestaw do bramki pull requestów na jednym symulatorze iOS i jednym emulatorze Androida, z zapisem artefaktów przy błędach.

Pierwszy prompt obejmuje kroki od 1 do 3 dla smoke flow.

Prompt do skopiowania: smoke flow Maestro zbadany na żywym urządzeniu

Use the Maestro MCP server. A simulator or emulator is already booted with our
debug build installed (app id com.yourcompany.app).

1. Walk the checkout happy path on the device: sign in with qa@example.com /
   the password in the E2E_PASSWORD environment variable, open the first product
   on the home feed, tap "Add to cart", open the cart, tap "Checkout", pay with
   test card 4242 4242 4242 4242 (any future expiry, any CVC).
2. Every element you touch must have a stable id. Where one is missing, add a
   testID in the React Native component and tell me which files you changed.
3. Write the path as .maestro/checkout-smoke.yaml: launchApp with clearState,
   select by id (fall back to text only for system UI), tag the flow "smoke",
   end with assertVisible on the order-confirmation id and takeScreenshot.
4. Keep it under 30 commands. No fixed sleeps; use extendedWaitUntil if a
   screen needs time.
5. Run it with `maestro test .maestro/checkout-smoke.yaml` until it passes
   twice in a row, then show me the final YAML and both run results.

Dla przepływów React Native, które wymagają obsługi uprawnień i precyzyjnej synchronizacji, lepszy jest Detox. Jego device.launchApp({ permissions }) nadaje lub odbiera uprawnienia przed startem aplikacji, ale tylko na iOS, dlatego prompt osobno opisuje ścieżkę dla Androida.

Prompt do skopiowania: zestaw Detox dla onboardingu ze ścieżkami uprawnień

Write a Detox test suite for our React Native onboarding flow in
e2e/onboarding.e2e.ts. Flow: Splash -> Welcome carousel (3 pages) ->
Notification permission -> Profile setup -> Home.

Cases:
1. Permission granted: iOS uses
   device.launchApp({ newInstance: true, permissions: { notifications: 'YES' } }).
2. Permission denied: iOS uses notifications: 'NO'. The Home screen must show
   the "Turn on notifications" banner (testID notif-banner).
3. Android: permissions cannot be preset through launchApp, so grant or revoke
   with adb shell pm grant / pm revoke com.yourcompany.app
   android.permission.POST_NOTIFICATIONS in a beforeAll, and document why.
4. Back navigation from every step returns to the previous screen.

Rules: match by testID only, no setTimeout or sleep (rely on Detox
synchronization; if a screen never goes idle, find the looping animation or
timer and tell me instead of disabling synchronization). Put shared login and
permission helpers in e2e/utils/. Run
`detox test -c ios.sim.debug e2e/onboarding.e2e.ts` and fix failures in the
tests, not in app logic, unless you show me the app bug first.

Gdzie każde narzędzie uruchamia pętlę na urządzeniu

Pętla na urządzeniu wymaga maszyny z symulatorami: symulatory iOS działają tylko na macOS z Xcode, a emulatory Androida potrzebują akceleracji sprzętowej. To przesądza, gdzie każdy agent wykonuje pracę.

Claude Code

Iteruj interaktywnie na Macu z podłączonym Maestro MCP. W CI zostaw uruchomienie testów deterministyczne i uruchamiaj agenta tylko do diagnozy błędu, z wąską listą dozwolonych narzędzi. claude -p startuje w trybie Manual i nie może pytać o zgodę, więc każde narzędzie spoza --allowedTools zostaje odrzucone:

claude -p "Read build/maestro/report.xml and the screenshots in build/maestro/. \
Explain why each failed flow failed and propose the smallest fix. Do not edit files." \
  --allowedTools "Read" "Glob" "Bash(maestro test *)" --output-format json

Codex

Iteruj w CLI albo rozszerzeniu IDE na maszynie z uruchomionym urządzeniem. Do nieinteraktywnej próby naprawy użyj codex exec z sandboksem workspace-write. Workspace-write domyślnie blokuje dostęp do sieci, co może odciąć agenta od adb lub symulatora. Zezwól na niego w tym uruchomieniu flagą -c sandbox_workspace_write.network_access=true albo uruchom krok na urządzeniu poza agentem i przekaż mu raport JUnit:

codex exec --sandbox workspace-write \
  "Read build/maestro/report.xml, fix the failing Maestro flows under .maestro/, and list what you changed."

Zadania w Codex cloud nadają się do pisania selektorów i flow na podstawie kodu, ale zanim poprosisz zadanie w chmurze o uruchomienie zestawu, sprawdź, czy twoje środowisko chmurowe w ogóle udostępnia symulator.

Cursor

Uruchamiaj agenta lokalnie w edytorze z podłączonym Maestro MCP i otwartym obok symulatorem, żeby widzieć każde stuknięcie na bieżąco. Cloud Agents działają na zdalnych maszynach wirtualnych; używaj ich do pisania selektorów i flow, a przebiegi na urządzeniach zostaw swojemu Macowi lub runnerowi CI, chyba że środowisko Cloud Agenta ma skonfigurowany emulator.

Samo zadanie CI uruchamia Maestro bezpośrednio, z tagami i raportem:

# CI: bramka smoke dla pull requestów
maestro test --include-tags smoke --format junit --output build/maestro/report.xml \
  --test-output-dir build/maestro .maestro/

W Detoksie detox test -c android.emu.release --take-screenshots failing --record-videos failing zapisuje dowody tylko dla nieudanych testów. W bramce nie włączaj --retries: ponowienie ukrywa niestabilność, którą chcesz mierzyć.

Skąd wiesz, że testy mobilne napisane przez agenta łapią błędy?

Zielony przebieg dowodzi tylko, że test i aplikacja się zgadzają. Nie dowodzi, że test zauważy regresję. Zamiast czytać każdą asercję, sprawdź cztery rzeczy:

Kontrola	Jak	Zaliczona, gdy
Kontrola negatywna	Zepsuj zachowanie, które test rzekomo pokrywa (ukryj przycisk, zwróć błąd z mocka API), i uruchom ponownie	Każdy test ze zmiany robi się czerwony z właściwego powodu
Higiena selektorów	grep po nowych flow i specach w poszukiwaniu selektorów tekstowych, stałych opóźnień i disableSynchronization	Żadnego wystąpienia bez komentarza z uzasadnieniem
Wskaźnik niestabilności	Uruchom nowy zestaw 10 razy na tym samym urządzeniu bez ponowień	10 na 10 przechodzi; każdy gorszy wynik trafia do kwarantanny, nie do bramki
Dowody	Zrzuty ekranu i nagrania przy błędach, raport JUnit w PR	Recenzent widzi, co działo się na urządzeniu, bez ponownego uruchamiania

Prompt do skopiowania: audyt kontroli negatywnej nowych testów mobilnych

For every Maestro flow and Detox test added or changed on this branch
(git diff main --name-only), do the following on the booted simulator:

1. Name the one user-visible behaviour the test protects.
2. Make the smallest app change that breaks that behaviour (remove the
   element, return a 500 from the mock server, skip the navigation call).
3. Run only that test. Record whether it failed, and whether the failure
   message points at the broken behaviour.
4. Revert the app change with git checkout -- <file> and confirm the test
   is green again.

Output a table: test, behaviour, mutation, failed (yes/no), message useful
(yes/no). Do not modify any test. Any test that stayed green is the finding.

Kto zatwierdza. Programista dołącza do pull requesta tabelę kontroli negatywnej i raport JUnit. Tech lead jest właścicielem dwóch list, których agent nie może zmieniać samodzielnie: tagów smoke blokujących merge i macierzy urządzeń. Umieść .maestro/, e2e/ i workflow CI w CODEOWNERS, żeby zmieniony lub usunięty test wymagał akceptacji człowieka; hooki i reguły, które to egzekwują, opisuje artykuł o ochronie wyroczni.

Na ilu urządzeniach trzeba testować?

Nie przetestujesz na każdym urządzeniu, a każde kolejne urządzenie wydłuża przebieg szybciej, niż zwiększa pokrycie. Podziel macierz na warstwy według częstotliwości uruchamiania:

Warstwa	Kiedy	Urządzenia	Cel
Bramka PR	Każdy pull request	1 symulator iOS (aktualny iOS), 1 emulator Androida (najniższy wspierany poziom API)	Tylko flow smoke; minuty, nie godziny
Nocna	Raz dziennie	3 do 6 symulatorów i emulatorów: najmniejszy i największy ekran, tablet, najstarszy wspierany system	Pełna regresja, układy, orientacja
Przed wydaniem	Przed każdym zgłoszeniem do sklepu	Prawdziwe urządzenia w farmie urządzeń (BrowserStack, AWS Device Farm), najczęstsi producenci z twojej analityki	Dialogi nakładek producentów, wydajność, prawdziwe iPhone’y

Prawdziwe iPhone’y są potrzebne w ostatniej warstwie, bo Maestro 2.11.0 nie działa na fizycznych urządzeniach iOS; na farmie urządzeń użyj do nich XCUITest lub Appium (npm appium 3.8.0).

Prompt do skopiowania: macierz urządzeń z twojej analityki

Design our mobile test device matrix from the attached analytics export
(analytics/devices-last-90-days.csv: platform, model, os_version, sessions,
crash_count).

Produce three tiers:
1. PR gate: exactly one iOS simulator and one Android emulator.
2. Nightly: at most six simulator/emulator configurations.
3. Pre-release: at most eight real devices for a device farm.

Selection rules: cover the lowest OS version we still support on each platform,
the smallest and largest screen, at least one tablet if tablets exceed 3% of
sessions, and the manufacturers with the highest crash_count per session, not
only the most sessions. For each device, give one sentence on which risk it
covers. Output the tiers as a table, then as the CI matrix YAML for
.github/workflows/mobile-e2e.yml (matrix section only).

Jak testować tryb offline i wolną sieć?

Żaden z frameworków nie ma jednego przełącznika warunków sieciowych działającego na obu platformach, więc steruj łącznością spoza testu:

• Tryb samolotowy na Androidzie: polecenia Maestro setAirplaneMode i toggleAirplaneMode działają tylko na Androidzie ze względu na ograniczenia symulatora iOS. adb shell svc wifi disable i adb shell svc data disable robią to samo ze skryptu.
• Zablokowane lub nieudane żądania: skieruj aplikację na serwer mockujący i wstrzykuj tam opóźnienia oraz odpowiedzi 5xx. device.setURLBlacklist([...]) w Detoksie sprawia, że test nie czeka na adresy analityki lub pollingu, które nigdy nie przechodzą w stan bezczynności.
• Symulowany offline na iOS: przekaż argument startowy (launchArgs: { offlineMode: true } w Detoksie albo zmienną środowiskową we flow Maestro), który aplikacja odczytuje, by udawać brak sieci — tylko w buildach debug.

Prompt do skopiowania: testy offline i ponownego połączenia

Write Maestro flows under .maestro/offline/ for our React Native app, tagged
"nightly", running on the Android emulator:

1. Offline banner: load the feed online, setAirplaneMode: enabled,
   assertVisible the offline banner (id offline-banner), setAirplaneMode:
   disabled, assert the banner disappears within 10 seconds.
2. Queued action: go offline, add an item to the cart, go online, and
   assert the cart badge shows exactly 1 item (no duplicate submission).
3. Cached data: after one online launch, go offline, relaunch the app
   without clearState, assert the last-loaded feed items are visible.

For iOS, where airplane mode cannot be toggled, write one Detox test that
launches with launchArgs { offlineMode: true } and asserts the same banner.
Tell me which app code reads offlineMode and confirm it is compiled out of
release builds.

Gesty, orientacja i układ działają według tego samego wzorca: Maestro ma swipe i setOrientation, Detox ma device.setOrientation(), swipe() na elementach i dostępne tylko na iOS pinch(). Dla regresji układu, których asercje dobrze nie opiszą, porównuj zrzuty ekranu i użyj kontroli ocenianej przez model z rubryką zamiast porównywania pikseli. Etykiety dostępności, VoiceOver i TalkBack opisuje artykuł o testach dostępności.

Kiedy testy mobilne pisane przez agenta zawodzą

Testy przechodzą na symulatorze, a padają na prawdziwych urządzeniach. Symulatory nie odtwarzają dialogów uprawnień z nakładek producentów, prawdziwych klawiatur ani ubijania aplikacji przy braku pamięci. Wyjście: przenieś te flow do warstwy przed wydaniem na farmie urządzeń i dodaj dialog producenta jako krok opcjonalny (optional: true w Maestro), a nie twardą asercję.

Agent „naprawił” nieudany test, osłabiając go. Typowe objawy to usunięte assertVisible, selektor tekstowy zamieniony na stuknięcie we współrzędne albo dodane w Detoksie disableSynchronization(). Wyjście: odrzuć zmianę, uruchom na tym teście prompt kontroli negatywnej i dodaj katalog testów do CODEOWNERS, żeby kolejne osłabienie wymagało akceptacji.

Flow są niestabilne przez animacje. Wyłącz animacje w procesie aplikacji, nie w teście: plik konfiguracji przestrzeni roboczej Maestro (config.yaml) obsługuje disableAnimations dla Androida i iOS, a na emulatorach Androida możesz ustawić trzy skale animacji na 0. Jeśli test nadal jest niestabilny: odłóż go do kwarantanny tagiem wykluczającym i poproś agenta o znalezienie zapętlonej animacji lub timera, przez które aplikacja nie przechodzi w stan bezczynności.

Agent nie widzi urządzenia. maestro mcp nie wystartuje bez Javy 17, a MobileBuildMCP wymaga macOS 14.5+ z Xcode 16+. Wyjście: uruchom ręcznie maestro test na jednym flow, żeby potwierdzić połączenie z urządzeniem, a potem sprawdź stan serwera przez /mcp w Claude Code albo codex mcp list.

Bramka PR jest za wolna. Zestawy mobilne działają wolniej niż webowe, a wolna bramka bywa pomijana. Wyjście: ogranicz bramkę do flow z tagiem smoke (celuj w trzy do pięciu ścieżek krytycznych), resztę przenieś do przebiegu nocnego i zrównoleglij go przez --shard-split w Maestro albo farmę urządzeń.

Co dalej z testowaniem mobilnym

Jak silna jest twoja wyrocznia? Wynik mutacyjny, kontrole negatywne i niestabilność: poprzeczka, którą zestaw musi przeskoczyć, zanim mu zaufasz.

Ochrona wyroczni Jak powstrzymać agenta przed edytowaniem lub usuwaniem testów, które sprawdzają jego własną pracę.

Automatyzacja testów end-to-end Odpowiednik webowy: zestawy Playwright dla tych samych ścieżek użytkownika.

Strategie danych testowych Przygotowane konta testowe i fixture'y, dzięki którym flow mobilne są powtarzalne.

Testy wydajności Czas startu, gubione klatki i pamięć — mierzone, a nie zgadywane.

Wzorce programowania w React Native Konfiguracja projektu i pętle buildów, na których działają testy z tej strony.