Emulátor nestačí, potřebujete skutečná zařízení Emulátory a simulátory jsou rychlé a levné, ale nezachytí skutečné chování hardwaru. Na fyzickém zařízení se projeví zahřívání, spotřeba baterie, přesnost GPS, kvalita fotoaparátu nebo zpoždění dotykové vrstvy. Praktický postup je takový, že většinu testů odjedete na emulátoru a na reálná zařízení nasadíte jen klíčové scénáře: první spuštění, přihlášení, platbu, práci s daty a přechod mezi sítěmi. Vyberte zařízení podle statistik vašich uživatelů, ne podle toho, co zrovna leží v šuplíku.

Testování mobilních aplikací se od testování webu liší víc, než se na první pohled zdá. Nejde jen o jinou velikost obrazovky. Aplikace běží na zařízení s omezeným výkonem, přerušovaným připojením, různými verzemi operačního systému a agresivní správou baterie. Pokud se tyto faktory ignorují, testovací scénáře projdou na vývojářském stroji, ale v reálném provozu aplikace padá nebo se chová nepředvídatelně.

Pro testování více vstupů slouží parametrizace. Dekorátor @pytest.mark.parametrize předá funkci sadu hodnot a pytest postupně spustí každou kombinaci. Výsledkem je přehledný report, který u každého případu ukáže, zda prošel. U výjimek se používá kontextový manažer pytest.raises. Ověříte jím nejen typ výjimky, ale i text zprávy. Pozor na příliš široké zachytávání – test, který projde u jakékoli chyby, neověřuje nic užitečného.

Jak nastavit hranici, která vydrž

Základem je rozdělit testování na dvě rovnocenné části: automatizované a manuální. Automatizace se vyplatí u regresních testů, opakovaných scénářů a kontrol rozhraní API. Manuální testování naopak odhalí problémy s ovládáním, čitelností textu, chováním při rotaci displeje nebo při příchozím hovoru. Snaha automatizovat úplně vše vede k sadě testů, které jsou křehké, pomalé a nikdo je neudržuje.

Mezi typické chyby patří i testování pouze v ideální síti. Přepněte zařízení do režimu s vysokou latencí, vypněte data uprostřed nahrávání souboru nebo simulujte ztrátu připojení. Sledujte, zda aplikace zobrazí srozumitelnou chybu, zda se data neztratí a zda se po obnovení připojení stav sám opraví. Právě tyto situace rozhodují o tom, zda uživatel aplikaci po prvním problému otevře znovu.

Častou chybou je testovat pouze na nejnovější verzi systému. Uživatelé s staršími verzemi tvoří nezanedbatelnou část a právě tam bývají problémy s kompatibilitou. Stejně tak se vyplatí testovat na zařízeních s malým množstvím úložiště a s omezeným výkonem. Aplikace, která se tváří plynule na výkonném telefonu, může být na slabším zařízení nepoužitelná.

Většina vývojářů dnes ví, že se mají vyhýbat skládání SQL dotazů pomocí řetězců. Přesto se SQL injection drží na předních příčkách chyb v bezpečnosti webových aplikací. Důvod není neznalost základního pravidla, ale to, že se injektáž často schová tam, kde ji nikdo nečeká: v dynamicky sestavovaných klauzulích ORDER BY, v názvech tabulek nebo v dávkovém zpracování. Tam parametrizace v tom nejběžnějším slova smyslu nefunguje, protože databázový engine nedovolí předat identifikátor jako parametr.

Nezapomínejte na přístupnost a lokalizaci. Otestujte aplikaci s větším zvětšením textu, s čtečkou obrazovky a v jazyce, který má delší názvy tlačítek. České překlady bývají delší než anglické a často rozbíjí rozložení obrazovky. Stejně důležité je sledovat chování po aktualizaci aplikace, kdy se mohou stará data dostat do konfliktu s novou strukturou. Testování není jednorázová aktivita před vydáním, ale průběžná součást vývoje, která se vyplatí nejvíc ve chvíli, kdy ji nikdo neodbývá.

Od jednoho souboru k opakovanému skriptu První automatizace nemá být robustní systém, ale něco, co zvládnete pochopit celé. Vezměte úkol, který děláte alespoň dvakrát týdně, a přepište ho do souboru skript.py. Pro práci se soubory a cestami používejte modul pathlib, pro text open() s kontextovým manažerem with, pro CSV modul csv. Cesty nikdy neskládejte ručně přes lomítka, protože se to na různých systémech chová jinak. Když skript funguje, spouštějte ho z terminálu, ne přes dvojklik — uvidíte chybové výpisy a rychleji pochopíte, co se pokazilo.

Pomáhá i to, když odhad rozložíte na části. Místo jednoho velkého data uveďte milníky: „do pátku bude hotová analýza, do dalšího týdne prototyp, finální verze pak podle toho, co vyplyne z prototypu." Zákazník vidí, že se něco děje, a vy máte přirozené kontrolní body, kde můžete odhad zpřesnit. Zároveň tím zabráníte tomu, aby se celý projekt hodnotil podle jednoho data na konci.