Co se stane, když jednotkové a integrační testy nevyvážíte včas

Při vývoji mobilní aplikace je testování stejně důležité jako psaní kódu. Bez něj se nevyhnete pádům, špatnému výkonu nebo frustrujícím chybám v uživatelském rozhraní. Než ale začnete, rozhodněte se, jakou strategii zvolíte. Většina týmů kombinuje dva základní přístupy: manuální testování pro rychlou kontrolu funkcí a automatizované testy pro opakující se scénáře. Manuální testování je nenahraditelné při objevování neočekávaných situací, ale je pomalé a náchylné k chybám. Automatizace zase šetří čas, ale vyžaduje počáteční investici do psaní testů. Klíčové je najít rovnováhu podle velikosti projektu a rozpočtu.

Jak správně strukturovat akce a reducery, aby se aplikace nezacyklila Další oblast, kde se dělá hodně chyb, je návrh akcí a reducerů. Mnoho vývojářů píše reducery tak, že mění stav více úrovní do hloubky pomocí spread operátoru, ale zapomíná, že každá taková změna musí být neměnná. Pokud přímo změníte část stavu, Redux si toho nevšimne a aplikace se neaktualizuje. Proto vždy vytvářejte nové objekty a pole. Prakticky to znamená: místo abyste dělali state.items.push(newItem), vraťte nové pole rozšířené o novou položku. To je základ, ale pozor na to, že hluboká struktura stavu vyžaduje složité kopírování, které je náchylné na chyby. Řešením je normalizovat stav – držte data jako slovník podle id, ne jako vnořená pole.

Když už víte, co do store patří, je klíčové správně používat selektory. Častým zlozvykem je předávat komponentě celý objekt store a nechat ji, ať si z něj vybere, co potřebuje. To ale vede k tomu, že komponenta se znovu vykreslí při každé změně jakékoli části store, i když se její data nezměnila. Místo toho používejte selektory, které vrací konkrétní hodnotu nebo derivovaný stav. V Reactu s Reduxem se vyplatí kombinovat je s hookem useSelector, který automaticky porovnává předchozí a novou hodnotu. Pokud selektor vrací nový objekt pokaždé, když se store změní, docílíte opačného efektu – nekonečných rerenderů.

Jak začít s testováním a na co si dát pozor Nejprve si ujasněte, co přesně chcete testovat. Zaměřte se na tři hlavní oblasti: funkčnost (například přihlášení nebo nákupní košík), výkon (rychlost načítání, spotřeba baterie) a uživatelskou přívětivost (ovládání jednou rukou, čitelnost). Pro manuální testy si vytvořte seznam kritických scénářů – od registrace až po odhlášení. Testujte na reálných zařízeních i emulátorech, protože každý přístup odhalí jiné problémy. Emulátory jsou rychlé, ale neodhalí například problémy se senzory nebo GPS. Při automatizaci začínejte s malým počtem testů, které pokrývají hlavní toky. Postupně přidávejte okrajové případy, ale nepřehánějte to – každý automatizovaný test vyžaduje údržbu, která se prodraží.

Další past je nepoužívání validátorů. Po napsání kódu si ho projděte v nástroji pro kontrolu syntaxe. HTML a CSS mají přísná pravidla a chybějící uvozovka nebo špatně zapsaná hodnota může rozbít celou stránku. Validátor najde chyby, které byste jinak hledali hodiny. Také se vyplatí testovat v různých prohlížečích, protože každý má drobné odchylky. Nezapomínejte ani na přístupnost: alt texty u obrázků, správné nadpisy a kontrast barev. To není jen o etice, ale i o SEO a použitelnosti pro všechny uživatele.

Nakonec si hlídejte výkonnost celé aplikace. Redux je skvělý nástroj, ale pokud ho používáte na každou drobnost, stává se přítěží. Použijte React.memo nebo useMemo na komponenty, které odebírají data ze store, a zvažte, zda některé části stavu nemají zůstat lokální. Pokud aplikace začne být pomalá, zkontrolujte, kolik komponent se re-renderuje při jedné akci – to je ukazatel, že máte příliš mnoho závislostí. Dobrým testem je přidat do komponenty console.log s názvem komponenty a sledovat, kdy se loguje. Často zjistíte, že se vykreslují i ty, které se změny netýkají.

Na závěr si osvojte používání plánovačů úloh, ať už jde o Cron v Linuxu nebo Plánovač úloh ve Windows. Skript, který běží ručně, je jen poloviční řešení. Naplánujte si ho na dobu, kdy nepotřebujete počítač, a ověřte, že logy obsahují dostatek informací k tomu, abyste po probuzení poznali, co skript dělal. Typická chyba je ignorovat výstup skriptu a spoléhat, že se nic nepokazí. Když se ale něco pokazí a vy nemáte žádný záznam, budete muset celý proces ladit od začátku. S trochou disciplíny se z vás stane někdo, kdo místo klikání myší píše pár řádků kódu a nechá práci běžet sám.

Dále se zaměřte na dobu běhu. Pokud máte testy, které trvají déle než pět minut, rozdělte je do vrstev: rychlé (jednotkové), střední (integrace s jednou komponentou) a pomalé (end-to-end). Rychlé spouštějte při každém commitu, střední při každém pull requestu a pomalé až před nasazením do produkce. Tím zajistíte, že vývojáři dostanou zpětnou vazbu rychle, ale složité scénáře nezmizí. Nezapomeňte také na flaky testy – pokud test občas selže bez zjevné příčiny, buď ho opravte, nebo zahoďte. Jinak začnete ignorovat červené výsledky a celý systém ztratí důvěryhodnost.