Praktický postup je zavést pyramidu do CI postupně. Nejprve zrychlete jednotkové testy tak, aby běžely do několika sekund. Pak přidejte integrační sadu, která se spouští při každém commitu. End-to-end testy nechte na noční běh nebo před vydáním. Sledujte dobu běhu a flakiness. Každý test, který občas padá bez změny kódu, buď opravte, nebo smažte. Nespolehlivá sada je horší než žádná.

Typická chyba je testovat jen na zařízení, na kterém vývojář pracuje. Aplikace se pak rozbije na telefonu s menší pamětí nebo na systému, kde uživatel omezuje běh na pozadí. Další častá chyba je ignorovat přerušení: příchozí zpráva, nízký stav baterie, přepnutí do jiné aplikace. Zkuste tyto situace nasimulovat ručně a sledujte, zda se data neztratí a zda se aplikace vrátí do stejného stavu.

Začněte tím, že si sepíšete, co vlastně testujete. U každé části kódu si položte otázku, zda jde o čistou logiku, spolupráci komponent, nebo chování celého systému. Jednotkový test má pokrýt rozhodování, hraniční hodnoty a chybové stavy. Integrační test ověří, že spolu moduly mluví správně přes rozhraní, databázi nebo frontu. End-to-end test patří jen na kritické cesty, které musí fungovat vždy, například dokončení objednávky.

Emulátor nestačí, potřebujete i reálný hardware Emulátory a simulátory jsou rychlé a pohodlné, ale mají limity. Nezachytí přesně spotřebu baterie, chování dotykového panelu při rychlém psaní, ani to, jak aplikace reaguje, když přijde hovor nebo když se telefon přehřeje. Uvolněte si proto alespoň dvě až tři skutečná zařízení s různými verzemi operačního systému a různě velkými displeji. Testujte na starším i novějším modelu, protože výrobci se chovají odlišně k oprávněním, oznámením a běhu na pozadí.

Druhá chyba je přílišné mockování. Když je každá závislost nahrazená atrapou, test neověří nic skutečného. Držte se pravidla: mockujte jen to, co je pomalé, nedeterministické nebo mimo vaši kontrolu. Databázi v integračních testech raději spouštějte skutečnou, klidně v kontejneru, a po každém testu ji resetujte. Testy tak zůstanou věrohodné a přitom opakovatelné.

Testování mobilních aplikací není jednorázová činnost před vydáním. Je to soubor návyků, které se opakují při každé změně kódu. Rozdíl mezi funkční aplikací a aplikací, která uživatele naštve, často nespočívá v počtu testů, ale v tom, jestli se testuje na správných místech a se správnými daty.

Kde pyramida v praxi selhává Nejčastější chyba je nahrazení pyramidy zmrzlinovou kornoutkem: mnoho pomalých end-to-end testů a skoro žádné jednotkové. Vzniká to tak, že se testy píší až po nasazení a přes uživatelské rozhraní. Řešení není psát víc testů, ale přesunout odpovědnost níž. Když test selže, má být jasné, která vrstva to způsobila. Pokud k opravě potřebujete spustit celou aplikaci, test je příliš vysoko.

Když reducery i async akce pokryjete takto izolovaně, odhalíte většinu chyb ještě před spuštěním aplikace. Integrační testy pak řeší jen to, co je skutečně integrační: propojení storu, middleware a komponent. Bez této vrstvy se integrační testy zvrhávají v pomalé a nespolehlivé běhy, které neřeknou, kde přesně se co pokazilo.

Než začnete ladit detaily, otestujte tok s pěti lidmi. Sledujte, kde se zaseknou, ne co říkají, že se jim líbí. Opravte jedno místo, otestujte znovu. Design není fáze projektu, ale průběžná kontrola toho, jestli rozhraní dělá to, co jste zamýšleli. Nejčastější chyba není nedostatek talentu, ale přeskočení tohoto kroku.

Většina týmů dělá retrospektivu pravidelně, ale málokdy z ní něco vznikne. Schůzka se zvrhne v obecné stesky, několik lidí mlčí a za dvě hodiny se rozejdete s pocitem, že se nic nezměnilo. Příčina nebývá v lidech, ale ve formátu. Strukturovaná zpětná vazba je způsob, jak z rozhovoru vytáhnout konkrétní informace, které se dají řešit. Nejde o žádnou metodu z konference, ale o obyčejnou disciplínu v tom, jak lidé mluví.

Reducery jsou čisté funkce. To je jejich největší výhoda při testování: na vstupu dostanou stav a akci, na výstupu vrátí nový stav. Nepotřebujete k tomu žádné integrační prostředí, server ani prohlížeč. Stačí testovací runner, který umí spouštět JavaScript, a knihovna pro aserce. Pokud reducer zapisuje do globálního stavu, sahá na Date.now() nebo na Math.random(), přestává být čistý a testy začnou být křehké. Takové závislosti vytáhněte do parametrů akce nebo je obalte vlastním modulem, který v testu nahradíte.

U async akcí se vyplatí testovat tři scénáře: úspěch, chybu a okamžik před dokončením. U úspěchu ověřte, že se nejdřív odešle akce o zahájení a pak akce s daty. U chyby zkontrolujte, že se odešle akce s chybou a že se nezavolá úspěšná větev. U zpožděné odpovědi ověřte, že se stav nemění, dokud promise nedoběhne. Nepoužívejte pevné časovače typu setTimeout v testech, pokud to jde; místo toho použijte promise a čekejte na jeho vyřešení.