Když se vám kód zamotá, sáhněte po těchto zásadách

Při automatizaci testů se zaměřte na stabilní a pomalé UI prvky, jako jsou přihlašovací formuláře, nákupní košík nebo onboarding. Automatizace mobilních testů je náročnější než u webu kvůli dynamickým prvkům a animacím. Používejte nástroje, které umožňují čekání na prvek na základě podmínky, ne jen pevný časový limit. Častou chybou je spoléhat na „sleepy", které testy zpomalují a činí je křehkými. Místo toho definujte explicitní očekávání, kdy má být prvek viditelný nebo klikatelný.

Kdy se vyplatí sáhnout po cloudových zařízeních a kdy po fyzických? Pro začátek si vystačíte s lokálními emulátory a simulátory, ale ty neodhalí problémy s výkonem na slabším hardwaru nebo s teplotou procesoru při delším zatížení. Pokud vyvíjíte aplikaci pro širokou veřejnost, je rozumné investovat do přístupu k reálným zařízením přes cloudové služby. Umožní vám to testovat na stovkách modelů bez nutnosti fyzického vlastnictví. Pozor ale na to, že cloudové služby ne vždy simulují přesně chování senzorů (např. GPS, akcelerometr) nebo síťovou konektivitu. Proto kombinujte: klíčové scénáře ověřte na fyzických zařízeních, která máte k dispozici, a širokou škálu pokryjte cloudem.

Dalším častým problémem jsou vedlejší efekty. Funkce, která mění vnější stav, je past. Když voláte processOrder(user) a funkce tiše upraví globální pole, po čase už nikdo nebude vědět, kdo za to může. Místo toho vracejte nové hodnoty a nechte volajícího, aby se rozhodl, co s nimi udělá. Například const updatedUser = addItemToCart(user, item) je mnohem bezpečnější než funkce, která mění user přímo. Pokud potřebujete mutovat, dělejte to na jednom místě a pojmenujte to jasně.

Podle rychlosti a spolehlivosti rozdělte testy do vrstev Zaveďte pravidlo dvou rychlostí. Jednotkové testy běží při každém uložení kódu, integrační testy pouze před nasazením. Toto oddělení umožní vývojářům pracovat rychle, aniž by museli čekat na spuštění celé sady. Pro integrační testy vytvořte samostatný adresář nebo projekt a připojte je do pipeline až po úspěšném průchodu rychlých testů. Dbejte na to, aby integrační testy měly izolované prostředí – vlastní databázi a kontejnery, které se po běhu zlikvidují.

Začněte tím, že si oddělíte čistou logiku od vedlejších efektů. Reducer by neměl obsahovat žádné volání API, časování ani generování náhodných čísel. Pokud takovou logiku najdete v reduceru, přesuňte ji do action creatoru nebo do samostatné funkce. Tento krok je zásadní pro snadné testování, protože čisté funkce jsou předvídatelné. Typická chyba začátečníků je testovat reducer přes celý stor s middlewarem, což zbytečně zpomaluje běh testů a znesnadňuje izolaci chyb. Místo toho vytvořte reducer přímo a testujte ho jako jakoukoli jinou funkci.

Práce s poli a objekty skrývá další úskalí. Místo řetězení if a else použijte včasné ukončení — tzv. early return. Když funkce začne kontrolou neplatných vstupů a vrátí null nebo prázdnou hodnotu, hlavní logika zůstane na první úrovni odsazení. Vyhnete se tak pyramidám závorek, které se nedají číst. Také místo for cyklů zkuste map, filter a reduce. Tyto metody vyjadřují záměr — transformace, filtrování, agregace — a kód je pak kratší a přehlednější.

Při psaní testovacích scénářů se zaměřte na reálné uživatelské toky, ne jen na izolované funkce. Typickou chybou je testovat každé tlačítko zvlášť, ale neověřit, co se stane, když uživatel přeruší přihlášení, přijde hovor během platby nebo se mu vybije baterie v půlce nahrávání videa. Mobilní aplikace běží v prostředí plném přerušení, a proto je nezbytné testovat i tyto okrajové situace. Pomůže vám to odhalit problémy s ukládáním stavu, obnovením obrazovky nebo ztrátou dat, které by uživatele odradily.

Testování reducerů a async akcí nemusí znamenat stavět celé integrační prostředí. Redux sám o sobě je čistá knihovna, která nezávisí na DOMu ani na serveru. Pokud se omezíte na jednotkové testy, získáte rychlost i stabilitu. Stačí k tomu test runner, jako je Vitest nebo Jest, a pár pomocných funkcí. Reducer je obyčejná funkce, takže ho zavoláte s aktuálním stavem a akcí a porovnáte výsledek. Async akce, které používají thunk middleware, testujete podobně – mockujete závislosti a kontrolujete dispatchnuté akce.

SQL injection patří mezi nejstarší, ale stále nejnebezpečnější zranitelnosti webových aplikací. Útočník dokáže vložit vlastní SQL příkaz do dotazu, který aplikace posílá databázi. Přitom nepotřebuje žádné speciální nástroje – stačí mu formulář, URL parametr nebo hlavička, kterou aplikace předává do SQL dotazu. Pokud se to podaří, může číst citlivá data, měnit je, nebo dokonce získat plnou kontrolu nad serverem. Mnoho týmů přitom považuje tuto hrozbu za vyřešenou, protože používají ORM nebo frameworky. Realita je ale jiná: chyba vzniká v okamžiku, kdy se do dotazu dostane uživatelský vstup bez ošetření.