Jak testovat React Native a Flutter aplikace na Androidu
React Native a Flutter umožňují sdílet velkou část kódu mezi platformami, neodstraňují však rozdíly v operačním systému, oprávněních ani hardwaru. Automatizované testování proto musí znát použitý framework a zároveň ověřit chování, se kterým se uživatel setká na Android zařízení. Jedna univerzální sada není cílem za každou cenu.
Kde vznikají typické problémy
Společný kód může vytvářet dojem, že stačí otestovat jednu platformu. Systémové dialogy, notifikace, klávesnice, návrat z pozadí a správa oprávnění se však řídí Androidem. Chyba v tomto propojení se v testu samotné komponenty nemusí projevit.
Druhým problémem je dostupnost prvků pro automatizační nástroj. React Native převádí komponenty do nativního rozhraní, test však potřebuje stabilní identifikátory a správně nastavené vlastnosti přístupnosti. Flutter pracuje s vlastním stromem widgetů a prostřednictvím sémantického stromu poskytuje informace systémovým nástrojům. Pokud důležité prvky nemají smysluplná sémantická data, externí end-to-end test je nemusí spolehlivě najít.
Nestabilitu potom způsobují lokátory podle textu, pevná čekání a závislost na produkčních datech. Samotný framework aplikace tyto problémy nevyřeší.
Stejně tak je třeba vybrat situace, které jsou důležité pro konkrétní produkt. Přehled mobilních scénářů vhodných k automatizaci pomůže oddělit kritické cesty od okrajových kombinací.
Jak rozdělit testy do tří vrstev
Jednotkové a komponentové testy ověřují obchodní logiku a jednotlivé části rozhraní rychle a bez celého zařízení. React Native k tomu používá nástroje z ekosystému JavaScriptu; Flutter má jednotkové a widgetové testy přímo ve svém SDK.
Integrační testy frameworku kontrolují spolupráci větších částí aplikace. Flutter poskytuje balíček integration_test, který dokáže běžet na emulátoru i fyzickém zařízení. Jeho oficiální dokumentace však upozorňuje, že nedokáže přímo ovládat nativní rozhraní platformy, například dialogy oprávnění nebo notifikace. Takové scénáře potřebují doplňkový přístup.
End-to-end testy zvenčí spouštějí sestavenou aplikaci a ovládají ji z pohledu uživatele. Pro Android se podle potřeb hodí Appium nebo Maestro. Pokrýváme jimi menší počet kritických cest a interakce se systémem, nikoli každý detail logiky.
Jak připravit aplikaci na stabilní end-to-end testy
Nejprve zkontrolujeme strom prvků na reprezentativních obrazovkách. Důležitým ovládacím prvkům doplníme stabilní testovací identifikátory, názvy a sémantické role. Ty pomáhají automatizaci i přístupnosti, ačkoli automatizovaný test sám o sobě není auditem přístupnosti.
Potom vytvoříme pilot, který zahrnuje:
- hlavní scénář v aplikaci;
- jeden nativní dialog nebo oprávnění;
- návrat aplikace z pozadí;
- kontrolu výsledku přes rozhraní nebo API;
- běh na emulátoru i vybraném fyzickém zařízení.
U Flutteru nejprve ověříme, zda systémový sémantický strom poskytuje dostatek údajů pro běžný Android ovladač. Pokud ne, zvážíme přístup specifický pro daný framework; komunitní ovladače Appium je třeba posoudit také podle údržby a kompatibility. U Maestra ověříme konkrétní obrazovky a příkazy ve stejném pilotu.
Rozdíl mezi rychlým virtuálním během a fyzickým hardwarem vysvětluje článek Emulátor nebo reálné zařízení.
Co tím získáte
Každá vrstva ověřuje to, pro co je vhodná. Většina logiky získá rychlé testy, zatímco menší end-to-end sada potvrdí, že důležité cesty a systémové interakce fungují v sestavené Android aplikaci.
Stabilní identifikátory a sémantika snižují citlivost testů na změnu vzhledu. Pilot navíc včas ukáže, zda zvolený nástroj rozumí konkrétní implementaci React Native nebo Flutteru a jaké úpravy aplikace potřebuje.
Další krok
Vyberte jednu kritickou obrazovku a zkontrolujte její testovací identifikátory, sémantické role a chování při systémovém dialogu. Následně vytvořte pilot napříč všemi třemi vrstvami a každý detail ponechte v nejrychlejší vrstvě, která ho dokáže spolehlivě ověřit.