Realne testowanie hybrydowych aplikacji mobilnych

desi9n.pl logo desi9n.pl

Mapa strony
PL EN

Autor: Krzysztof Ścira

Jak testować hybrydowe aplikacje mobilne, gdy JavaScript nie sięga do natywnych wtyczek? Trzy typy kliknięć, ghost clicks, ograniczenia ADB i narzędzie Cordova Testing zbudowane przez desi9n.pl – prelekcja Krzysztofa Ściry z Mobile Trends Conference 2016 i lekcje, które zostały.

Schemat testowania hybrydowej aplikacji mobilnej – ADB, WebView, narzędzie Cordova Testing na emulatorze Android
Ilustracja pokazująca architekturę testowania aplikacji hybrydowej: interfejs testera, web service i natywne akcje przez ADB na urządzeniu Android.

Realne testowanie hybrydowych aplikacji mobilnych

19 lutego 2016 roku Krzysztof Ścira wygłosił na Mobile Trends Conference 2016 w Krakowie prelekcję zatytułowaną PRAWDZIWE testowanie hybrydowych aplikacji mobilnych, poświęconą praktycznym metodom testowania hybrydowych aplikacji mobilnych. Podczas gdy inne prezentacje skupiały się na budowaniu takich aplikacji, tu padło pytanie fundamentalne: jak sprawdzić, że to, co zbudowaliśmy, rzeczywiście działa — na prawdziwych urządzeniach, z prawdziwymi użytkownikami? Ponad 10 lat później wracamy do tej prezentacji, żeby zobaczyć, co z tamtej wiedzy przetrwało.

Dziś, z perspektywy 2026 roku, wiele konkretnych narzędzi i platform opisywanych w prelekcji odeszło do historii: Windows Phone przestał być wspierany, Crosswalk wycofano, AngularJS dobiegł końca. Jednak omawiane problemy — trzy typy kliknięć, ghost clicks, ograniczenia JavaScriptu, konieczność testowania na fizycznych urządzeniach — pozostają w pełni aktualne w każdym projekcie mobilnym.

Czym jest hybrydowa aplikacja mobilna?

Krzysztof otworzył prezentację od definicji — bo bez niej trudno sensownie rozmawiać o testowaniu. Aplikacja hybrydowa to trzy warstwy ułożone jedna na drugiej:

  • Jeden kod źródłowy — napisany w HTML5, JavaScript i CSS. Może korzystać z dowolnego frameworka: AngularJS, React, Aurelia i innych
  • WebView — komponent przeglądarki osadzony w natywnej aplikacji. To on renderuje kod webowy jak stronę internetową, ale wewnątrz zainstalowanej apki
  • Natywna powłoka aplikacji — paczka APK (Android), IPA (iOS) lub XAP (Windows Phone), którą użytkownik instaluje ze sklepu

Mostem między WebView a natywnym sprzętem urządzenia jest Apache Cordova (lub jego komercyjny bliźniak PhoneGap — technicznie to samo rozwiązanie, różnią się jedynie licencją). Cordova dostarcza system wtyczek, które otwierają dostęp do kamery, GPS, systemu plików, powiadomień push i dziesiątek innych funkcji niedostępnych w czystym HTML-u. Ionic to z kolei warstwa frontendowa — biblioteka komponentów UI zbudowana na szczycie Cordovy.

Osobną kwestią był Crosswalk — wtyczka zastępująca wbudowany WebView Androida silnikiem Chromium z nowszej wersji systemu. Na Androidzie 4.x (Ice Cream Sandwich, Jelly Bean) pozwalała uzyskać wydajność WebView z KitKata lub Lollipopa — kosztem dołożenia kilkunastu megabajtów do rozmiaru aplikacji.

Trzy typy kliknięć w testach mobilnych

Zanim Krzysztof przeszedł do narzędzi, wprowadził istotną klasyfikację: nie wszystkie kliknięcia w testach są równe. Wyróżnił trzy rodzaje:

1. Kliknięcia palcem

Najlepsza metoda — bezpośrednie dotknięcie ekranu przez testera. Jak ujął to Krzysztof: „Palce są dobre. Palce są ciepłe, wilgotne, ale to dobra rzecz" — bo odwzorowują dokładnie to, co robi prawdziwy użytkownik. Palec generuje zdarzenia dotykowe z fizycznymi koordynatami i presją, których żaden emulator nie odtworzy w stu procentach.

2. Natywne kliknięcia przez ADB

Android Debug Bridge (adb shell input tap X Y) pozwala symulować kliknięcia w określonych współrzędnych ekranu. To kliknięcie natywne — system operacyjny „widzi" je jak dotknięcie palca. Daje to znacznie więcej możliwości niż JavaScript, ale ma jedno poważne ograniczenie: współrzędne X i Y są stałe, więc test działa tylko na jednej rozdzielczości. Gdy treść generowana przez użytkownika zmienia układ ekranu, pozycja przycisku przesuwa się i test przestaje trafiać w cel.

3. Kliknięcia programatyczne przez JavaScript

Wywołanie element.click() lub symulacja zdarzenia na selektorze CSS. Metoda wygodna — selektor jest odporny na zmiany rozdzielczości, bo nie zależy od pozycji pikseli. Jednak JavaScript w WebView ma kilka twardych ograniczeń:

  • Można kliknąć element spoza widocznego obszaru ekranu — co daje inne zachowanie niż kliknięcie palcem, bo w rzeczywistości użytkownik tego elementu nie widzi
  • Można kliknąć element ukryty (display:none, visibility:hidden)
  • Z powodów bezpieczeństwa przeglądarka blokuje pewne akcje — na przykład kliknięcia w <input type="file"> i otwarcia okna wyboru pliku nie da się wywołać programatycznie

RWD a pułapki selektorów

Responsywny design (RWD) sprawia, że ten sam selektor CSS może wskazywać na kilka elementów jednocześnie. Klasyczny przykład: trzy przyciski z tą samą klasą, widoczne zależnie od breakpointa. Jeśli test nie precyzuje, który z nich kliknąć (np. przez indeks lub kontekst nadrzędny), selektor zadziała na wszystkich — i wynik testu będzie nieprzewidywalny. To subtelna, ale częsta przyczyna fałszywych pozytywów w automatycznych testach aplikacji hybrydowych.

Kliknięcia poza ekranem i element „hitable"

JavaScript pozwala kliknąć element, który istnieje w DOM, ale nie jest widoczny w bieżącym widoku ekranu. W testach automatycznych takie kliknięcie „przejdzie", ale w realnym scenariuszu użytkownik po prostu nie ma dostępu do tego elementu. To klasyczna rozbieżność między testem a rzeczywistością.

Analogiczny mechanizm istnieje w natywnych narzędziach: Xcode ma parametr hitable, który określa, czy komponent może być naciśnięty przez użytkownika. Android posiada odpowiednik tego atrybutu. W testach JavaScriptowych możemy sprawdzić podobną właściwość przez długość selektora i widoczność w DOM, ale wymaga to świadomego podejścia w pisaniu testów.

Osobna ciekawostka: element z absolutnym pozycjonowaniem i przezroczystym tłem nałożony na inny element może całkowicie blokować kliknięcia na element poniżej — choć sam jest niewidoczny. Test selektorem przejdzie bez problemu, ale tester z palcem doświadczy frustracji.

Testowanie wtyczek Cordova

Testy JavaScriptowe nie wystarczają tam, gdzie wtyczki Cordovy wywołują natywne funkcje systemu. Kiedy aplikacja otwiera aparat lub skaner kodów kreskowych, sterowanie przechodzi do natywnej aktywności Androida lub iOS — poza zasięgiem JavaScriptu w WebView. W tej warstwie nie można wywoływać zdjęć programatycznie, kliknąć „zatwierdź" w natywnym oknie wyboru pliku ani nawet sprawdzić, co widać na ekranie.

Konsekwencja jest prosta: wszędzie tam, gdzie aplikacja sięga po natywne funkcje urządzenia, testy muszą obejmować natywne akcje użytkownika. Nie da się tego w pełni zastąpić automatyzacją po stronie JavaScriptu.

Narzędzie Cordova Testing — architektura i działanie

Aby połączyć oba światy — wygodny interfejs testów z natywnym wykonaniem akcji na urządzeniu — Krzysztof pokazał narzędzie opracowane przez desi9n.pl: Cordova Testing. Architektura składa się z trzech warstw:

  • Tester UI — prosty interfejs webowy (Angular) dla testerów. Nie wymaga pisania kodu — tester definiuje akcje wizualnie i dodaje je do kolejki
  • Web service — serwer pośredniczący (Node.js), który odbiera komendy z interfejsu i przekazuje je do warstwy natywnej
  • Natywne akcje na telefonie — wykonywane przez adb shell input. Możliwe akcje to: tap na współrzędnych X/Y, wpisanie tekstu, symulacja klawiszy sprzętowych

W praktycznym demo Krzysztof pokazał logowanie do aplikacji działającej na emulatorze Android (OS X): zdefiniowanie sekwencji — kliknij pole email, wpisz dane, kliknij hasło, wpisz, kliknij „Zaloguj" — i uruchomienie całości jako jednej kolejki testowej. Emulator wykonał sekwencję w trybie natywnym, bez ingerencji JavaScriptu.

Zapis testów i integracja z CI/CD

Testy można zapisywać do plików JSON lub XML i uruchamiać je bezpośrednio przez web service — bez interfejsu graficznego. To otwiera drogę do integracji z procesem ciągłej integracji:

  • Bashowy skrypt monitoruje repozytorium Git i przy każdym nowym commicie pobiera zmiany
  • Uruchamia zdefiniowane testy na emulatorze (lub fizycznym urządzeniu podłączonym przez USB)
  • Rejestruje wyniki — np. czy logowanie przebiegło poprawnie, czy rejestracja zakończyła się sukcesem

Krzysztof zapowiedział też wsparcie dla iOS (przez analogiczne narzędzie konsolowe Apple) oraz — z mniejszym entuzjazmem — dla Windows Phone, z których jeden z uczestników wcześniej pytał o obsługę Google Keep i Google Drive.

Dlaczego testy automatyczne nie wystarczą?

Krzysztof zakończył myślą, która pozostaje aktualna niezależnie od roku i frameworka:

Testy automatyczne mogą weryfikować logikę i przepływ akcji. Nie weryfikują tego, co widzi użytkownik. Nawet jeśli wszystkie asserty przejdą, rendering na konkretnym urządzeniu może być zepsuty — błąd layoutu, nakładające się elementy, tekst wypadający poza kontener. Bez wzroku ludzkiego testera nie ma na to dowodu.

Stąd wniosek: w każdym poważnym projekcie mobilnym automatyzacja i testy manualne uzupełniają się nawzajem. Automatyzacja jest tańsza i szybsza dla powtarzalnych scenariuszy (logowanie, rejestracja, krytyczne ścieżki). Człowiek jest niezbędny przy weryfikacji UI na różnorodnym sprzęcie. Razem tworzą sensowny coverage.

Co zmieniło się od 2016 roku?

Minęło niemal 10 lat i krajobraz narzędzi testowania aplikacji mobilnych zmienił się znacząco:

  • Crosswalk — wycofany w 2017 roku; Android WebView jest od wersji 5.0 aktualizowany przez Google Play jako osobna apka, więc problem przestarzałych silników w dużej mierze zniknął
  • Windows Phone — oficjalnie zakończony w 2019 roku; platforma odeszła do historii zgodnie z przewidywaniami Krzysztofa
  • ADB — nadal centralny punkt automatyzacji testów na Androidzie. adb shell input wciąż działa, wciąż jest używany
  • Appium — open-source'owy framework testowania mobilnego, który rozwiązuje wiele opisywanych problemów: obsługuje zarówno iOS, jak i Android, abstrakcjonuje ADB i narzędzia Apple za wspólnym API
  • Detox, Maestro — nowsze narzędzia skoncentrowane na testach e2e React Native i aplikacji hybrydowych, z lepszym wsparciem dla asynchroniczności i animacji
  • Ghost clicks — problem nadal realny; rozwiązania jak pointer-events: none na czas animacji pozostają aktualną praktyką

Fundamentalne wyzwania — niejednorodność WebView na różnych urządzeniach, ograniczenia JavaScript w dostępie do natywnego sprzętu, konieczność testowania na fizycznych telefonach — nie znikły. Zmieniły się narzędzia, ale inżynierskie rozumowanie Krzysztofa z 2016 roku jest dalej aktualnym punktem odniesienia.

Podsumowanie

Prelekcja Krzysztofa Ściry z Mobilization VI pokazała, że testowanie aplikacji hybrydowych to więcej niż uruchomienie zestawu asertów. Trzy typy kliknięć, elementy poza ekranem, ograniczenia JavaScriptu, natywne wtyczki wymagające natywnych akcji — to problemy, które do dziś wracają w każdym projekcie opartym na WebView. Narzędzie Cordova Testing zbudowane przez desi9n.pl było wówczas praktyczną odpowiedzią: prosty UI, Node.js jako serwer, ADB jako egzekutor — i gotowa droga do CI/CD bez rezygnowania z testów na prawdziwym sprzęcie.

Budujesz aplikację mobilną i szukasz sprawdzonego podejścia do testów? Sprawdź, jak tworzymy i testujemy aplikacje mobilne w desi9n.pl i porozmawiaj z naszym zespołem o strategii QA dla Twojego projektu.

desi9n.pl na Mobile Trends Conference – historia wystąpień

Prelekcja z Mobile Trends Conference 2016 nie była ani pierwszym, ani ostatnim kontaktem desi9n.pl z tym wydarzeniem. Przez ponad dekadę Krzysztof Ścira regularnie pojawiał się na MTC – jako prelegent i jako uczestnik.

Tagi artykułu:

Czy podobał Ci się ten artykuł? Szukasz partnera, który pomoże Ci w realizacji nowoczesnych rozwiązań? Jeśli chcesz wdrożyć omawiane rozwiązania w swoim projekcie, skontaktuj się z nami i rozpocznijmy współpracę!

Kontakt