Redakcja
Projekt jest otwarty, napisany w TypeScripcie, rozwijany przez Mobile Next HQ – tych samych ludzi, którzy stoją za Mobile MCP. Na stronie projektu widnieje już ponad 4800 obserwujących i gwiazdek społeczności, choć samo repozytorium GitHub jest jeszcze na bardzo wczesnym etapie rozwoju. To niemałe zainteresowanie, jak na projekt, który dopiero raczkuje.
Playwright, ale na telefonie
Jeśli ktoś pisał testy w Playwright, Mobilewright będzie znajomy od pierwszej linii. getByRole, getByLabel, getByText, łańcuchowanie lokatorów, asercje z auto-oczekiwaniem – to ta sama filozofia, tyle że przeniesiona na grunt mobilny. Nie jest to bezpośrednia adaptacja Playwright, bo warstwa komunikacji z urządzeniem jest zupełnie inna, ale API jest celowo skrojone tak, żeby minimalizować zaskoczenia.
Dla zespołów, które mają już testerów piszących testy webowe w Playwright, to konkretna oszczędność: te same osoby mogą pisać testy mobilne bez tygodnia nauki nowego API i bez dwóch różnych konwencji w jednym projekcie.
Drzewo dostępności zamiast współrzędnych
Pod spodem Mobilewright nie operuje na zrzutach ekranu ani pikselach. Komunikuje się z drzewem dostępności urządzenia – XCUIElementType na iOS, Android Accessibility na Androidzie. Testy operują na semantyce interfejsu: przyciskach, polach tekstowych, zakładkach, nagłówkach. Nie ma XPath ani selektorów CSS.
Takie podejście zwykle lepiej znosi zmiany układu interfejsu. Jeśli przycisk zmieni pozycję na ekranie, bo zmieniła się kolejność elementów albo przeprojektowano layout, test nadal działa, bo szuka przycisku po jego roli i etykiecie, a nie po współrzędnych. Testy psują się, gdy zmienia się semantyka interfejsu, nie jego wygląd.
Z tego samego powodu Mobilewright nadaje się do sterowania przez agenty AI, ale o tym niżej.
Koniec z ręcznym zarządzaniem oczekiwaniem
Jeden z bardziej żmudnych aspektów testów mobilnych to timing: animacje, wolne ładowanie widoków, asynchroniczne zapytania. Klasyczne podejście to ręczne wstawianie opóźnień albo własne pętle oczekujące. Oba rozwiązania są kruche i trudne w utrzymaniu.
Mobilewright rozwiązuje to inaczej. Każda akcja ma oczekiwanie wbudowane. Przed tapnięciem, wypełnieniem pola czy długim przytrzymaniem framework sprawdza, czy element istnieje, czy jest widoczny, aktywny i czy ma stabilne wymiary – czyli czy nie jest właśnie w trakcie animacji. Sprawdzenia odbywają się co 100 ms (dla stabilności wymiarów co 50 ms). Akcja wykonuje się dopiero, gdy wszystkie warunki są spełnione.
Asercje działają tak samo. Sprawdzenie widoczności elementu nie jest jednorazową operacją, tylko pętlą z domyślnym timeoutem 5 sekund. Timeout można nadpisać globalnie w pliku konfiguracyjnym albo osobno dla każdej akcji.
Co Mobilewright obsługuje, a czego nie
Mobilewright działa z szeroką gamą technologii: UIKit, SwiftUI, Jetpack Compose, React Native, Expo, .NET MAUI, NativeScript, Cordova i Capacitor. Wspólny mianownik to natywna warstwa dostępności – o ile framework renderuje standardowe elementy dostępnościowe, testy działają.
Wyjątek to Flutter, który renderuje przez własny silnik graficzny z pominięciem natywnej warstwy dostępności. Wsparcie jest zaplanowane, ale wymaga osobnego sterownika opartego na DartVM Service. Podobnie Kotlin Multiplatform z Compose Multiplatform na iOS – Android działa, iOS jest w toku.
Wiele urządzeń naraz
Mobilewright uruchamia testy równolegle przez workery. Każdy worker to jeden proces podłączony do jednego urządzenia lub symulatora. Urządzenia są przydzielane dynamicznie: jeśli potrzebne urządzenie jest wolne, test startuje natychmiast; jeśli wszystkie są zajęte, test czeka w kolejce.
Dla bardzo dużych zestawów testowych przy lokalnych symulatorach (jedna maszyna zwykle wytrzymuje 2-4 symulatory zanim spada wydajność) framework obsługuje sharding – podział testów między kilka maszyn CI. Przy zdalnych chmurach urządzeń sharding jest zbędny, bo wąskim gardłem nie jest maszyna uruchamiająca testy, lecz dostępność urządzeń w puli.
Testy niestabilne można automatycznie ponawiać. Retry jest zaprojektowany tak, żeby nie alokować za każdym razem nowego urządzenia. Framework odłącza się, wraca do puli, podłącza ponownie do tego samego urządzenia i restartuje aplikację. Alokacja odbywa się raz na sesję.
Agenty AI i dostęp do telefonu
Mobilewright wspiera protokół MCP, co otwiera scenariusz, który jeszcze niedawno wymagał modelu wizyjnego i dużo improwizacji: agent językowy sterujący prawdziwym telefonem. Agent czyta drzewo dostępności – strukturę interfejsu w postaci tekstowej – i wykonuje akcje dokładnie tak samo, jak test automatyczny.
Nie potrzeba do tego analizy zrzutów ekranu. Drzewo dostępności jest deterministyczne, a tokeny zużywane do jego przekazania agentowi to ułamek tego, co kosztuje analiza obrazu. Dla zespołów eksperymentujących z agentami to jedno z nielicznych gotowych rozwiązań do aplikacji mobilnych, bez budowania własnej infrastruktury.
Ekosystem i stan projektu
Architektura pakietów jest warstwowa. Główny pakiet mobilewright wystarczy do większości zastosowań. @mobilewright/test dodaje test fixtures i runner inspirowany Playwright Test. Osobne pakiety obsługują protokół komunikacji, drivery (lokalny przez mobilecli, chmurowy przez mobile-use.com) i rdzeń z logiką lokatorów i asercji.
Wystarczy jedno polecenie, żeby zainicjować projekt. Polecenie npx mobilewright doctor sprawdza środowisko – Xcode, Android SDK, podłączone urządzenia, ADB – i przy brakujących zależnościach mówi wprost, co i jak naprawić. Raporty HTML z filtrowaniem wyników, zrzutami ekranu i nagraniami wideo działają od razu, bez dodatkowej konfiguracji.
Projekt jest młody. Być może przy obecnej wersji nie warto ślepo ufać stabilności API w środowisku produkcyjnym, jednak mimo wszystko changelog jest aktywny, commity pojawiają się codziennie, co jest dobrym znakiem, ale też oznacza, że rzeczy mogą się zmieniać. Dla nowych projektów mobilnych, gdzie nie ma co migrować, to dobry moment na wejście, a dla istniejących zestawów testów Appium warto poczekać na kilka kolejnych wersji i ocenić, czy API ustabilizowało się wystarczająco, zanim zacznie się szacować koszt przepisania.
Więcej o narzędziu na oficjalnej stronie: mobilewright.dev
GitHub narzędzia: github.com/mobile-next/mobilewright
Sprawdzaliście już Mobilewright? Dajcie nam znać o swoich wrażeniach na naszym forum, na którym zastanawiamy się, czy Mobilewright ma szansę zastąpić Appium.
