První unit test vzniká obvykle ve chvíli, kdy už nějaká funkce funguje a ty chceš mít jistotu, že ji nerozbiješ při další úpravě. Než začneš psát testovací kód, potřebuješ vědět, co přesně budeš testovat. Vyber jednu malou funkci, která má jasný vstup a výstup. Nepokoušej se otestovat celý modul najednou, rozděl ho na menší celky. Čím menší jednotka, tím snáz odhalíš, co selhalo.
Kde končí jednotkový test a začíná integrační Integrační testy ověřují spolupráci mezi komponentami: repository a databází, HTTP klientem a serverem, frontou a konzumentem. Bývají pomalejší a křehčí, proto jich má být výrazně méně než jednotkových. Častá chyba je nahrazovat jimi jednotkové testy, protože se snadněji píší. Výsledkem je pomalý běh a nejasná příčina selhání. Pomáhá používat reálné závislosti v kontejneru, ale s pevně danými daty a úklidem po každém testu.
Jakmile budeš mít funkční jednoduchou aplikaci, přidej druhou obrazovku a navigaci mezi nimi. Potom zkus uložit data tak, aby přežila zavření aplikace. Teprve pak řeš vzhled, animace nebo síťovou komunikaci. Když budeš postupovat po malých krocích, dřív zjistíš, co ti sedí, a hlavně budeš mít hotovou věc, kterou můžeš někomu ukázat. To je lepší než měsíce číst a nezkusit nic napsat.
Praktický postup: nejdřív napište jednotkový test pro novou logiku, pak integrační pro hranici systému a e2e jen pro scénář, který by jinak nikdo neověřil. Sledujte dobu běhu. Pokud sada jednotkových testů trvá déle než několik sekund, něco děláte špatně. Pokud integrační testy vyžadují ruční spuštění databáze, ztratí se v CI a přestanou se spouštět.
Pull request není jen místo pro schválení. Je to poslední šance odhalit chyby dřív, než se dostanou do hlavní větve. Nastavte si ochranu hlavní větve tak, aby vyžadovala alespoň jedno schválení a zelené testy. Do popisu pull requestu napište, co změna řeší a jak ji ověřit — recenzent pak nemusí hádat. Vyhněte se dvěma krajnostem: schvalování bez čtení a blokování kvůli stylistickým drobnostem, které patří do automatické kontroly.
Během diskuze držte tři kategorie: co bylo dobré, co bylo špatné a co je nejisté. Třetí kategorie je často nejužitečnější, protože se v ní skrývají věci, o kterých se mlčí. Každý bod se musí převést na rozhodnutí: buď se změní, nebo se výslovně řekne, proč se měnit nebude. Neslibujte, že se něco udělá, když na to není kapacita. Prázdný slib je horší než žádný, protože příští retrospektiva začne nedůvěrou.
Čtvrtým krokem je otestovat, zda je licence v praxi vymahatelná a srozumitelná. Soubor s licencí patří do kořene projektu, v hlavičkách zdrojových souborů má být stručná zmínka. Častá chyba je neúplný nebo rozporuplný licenční text, který v praxi nikdo neumí vyložit. Stejně problematické je napsat vlastní licenci bez právního základu. Pokud si nejste jistí, použijte existující osvědčenou licenci a jen doplňte, kdo je držitelem práv.
Častou chybou začátečníků je testování implementace místo chování. Testuj to, co funkce dělá, ne jak to dělá. Pokud test závisí na vnitřním stavu nebo pořadí volání, bude křehký a při každé refaktorizaci se rozbije. Další chybou je příliš mnoho očekávání v jednom testu. Takový test je nepřehledný a jeho selhání nic neřekne. Vyhni se také testům, které nikdy neselžou, protože nemají žádné ověření.
Základ tvoří jednotkové testy. Mají být rychlé, izolované a bez sítě, databáze i souborového systému. Testují jednu funkci nebo třídu, ne tok přes aplikaci. Typická chyba: test obsahuje příliš mnoho tvrzení a při pádu není jasné, co se rozbilo. Držte se pravidla, že jeden test ověřuje jednu věc. Pokud příprava dat zabere víc řádků než samotná aserce, je to signál, že logika patří jinam.
Na vrcholu stojí end-to-end testy. Ověřují scénář z pohledu uživatele, ale jsou nejdražší na údržbu. Nemá smysl jimi pokrývat každou kombinaci vstupů. Vyberte kritické cesty: přihlášení, platba, uložení objednávky. Pokud e2e test padá kvůli změně textu v tlačítku, je příliš křehký a patří do nižší vrstvy. Stabilita je důležitější než pokrytí.
Největší chybou je poměr obrátit: mnoho e2e testů a málo jednotkových. Další je sdílený stav mezi testy. Test, který projde sám, ale selže v sadě, obvykle závisí na datech z předchozího běhu. Řešením je izolace a deterministická data. Pyramidu nevnímejte jako početní poměr, ale jako rozhodnutí, kde zaplatíte za rychlost a kde za věrnost.
Struktura testu: příprava, akce, ověření Každý test by měl mít tři jasné části. Nejprve připrav vstupy a závislosti. Potom zavolej testovanou funkci. Nakonec ověř, že výsledek odpovídá očekávání. Tento vzorec se nazývá Arrange-Act-Assert a drž se ho i v prvním testu. Pokud funkce pracuje s databází nebo soubory, nahraď je jednoduchými atrapami. Test nesmí záviset na externím prostředí, jinak bude pomalý a nespolehlivý.