Co se stane, když poprvé zavoláte API a jak se vyhnout nejčastějším chybám
Základní metrikou je řádkové pokrytí, které zjistíte pomocí nástrojů, jež sledují, které řádky kódu byly při běhu testů spuštěny. Toto číslo je snadné získat, ale má zásadní nedostatek – neříká, jestli byly testy skutečně efektivní. Můžete mít sto procent pokrytí a přitom testovat jen happy path, zatímco chyby v edge casech zůstanou neodhalené. Proto byste měli vždy kombinovat řádkové pokrytí s pokrytím větví (branch coverage), které kontroluje, jestli byly projity všechny podmínky, a s pokrytím funkcí, které sleduje, zda byly volány všechny veřejné metody.<br>
<br>
<br>
<br>
Kdy přestává být pokrytí užitečné a co sledovat místo něj Pokrytí přestává být užitečné ve chvíli, kdy se stane cílem místo nástroje. Jakmile tým začne psát testy proto, aby číslo dosáhlo stanovené hranice, kvalita testů obvykle klesá. Typicky se objevují testy, které volají funkce bez jakýchkoli tvrzení o výsledku — jen aby se kód spustil. Takové testy zvyšují pokrytí, ale nechytí žádnou chybu. Druhý případ je nárůst počtu testů, které se liší jen vstupními daty, ale netestují žádnou další logiku. Pak sice roste číslo, ale ochrana systému zůstává stejná.<br>
<br>
<br>
<br>
Při interpretaci pokrytí vždy přihlížejte k tomu, kdo a jak měření používá. Pokud je pokrytí součástí code review a vývojáři ho berou jako zpětnou vazbu, je užitečné. Pokud se používá jako metrika pro hodnocení výkonu, začne se systém obcházet. Zkuste si položit otázku: objevíte díky tomuto číslu chybu, kterou byste jinak přehlédli? Pokud ne, přesuňte pozornost k testům, které ověřují chování systému, ne jen to, že se kód spustil. Pokrytí je jen jeden indikátor, ne cíl vývoje.<br>
<br>
<br>
<br>
Prakticky to uděláte tak, že si v nástroji pro měření pokrytí nastavíte hlášení o tom, které řádky nebyly pokryty, a pravidelně si je prohlížíte. Když najdete nepokrytý řádek, zeptejte se sami sebe, proč tam je. Pokud je to obsluha chyby, kterou testy nikdy nevyvolají, možná je v pořádku, že ji testy neprocházejí – ale pokud je to hlavní logika, máte problém. Dalším krokem je měření pokrytí mutací, které vám řekne, jestli testy skutečně odhalí chyby. Tato metoda spočívá v tom, že se do kódu záměrně vloží drobné změny (mutace) a zjistí se, kolik z nich testy odhalí. Pokud je mutační skóre nízké, vaše testy jsou slabé, i když je řádkové pokrytí vysoké.<br>
<br>
<br>
<br>
Důležité je také rozhodnout, jak často slučovat změny do hlavní větve. Doporučuji slučovat alespoň jednou denně, ideálně po každé dokončené části práce. Čím déle větev žije, tím větší je riziko konfliktů. Než začnete slučovat, vždy si aktualizujte svou větev z hlavní větve. To znamená, že si stáhnete změny, které mezitím přibyly, a vyřešíte případné konflikty ještě před samotným sloučením. Tím se vyhnete velkým a nepřehledným merge konfliktům.<br>
<br>
<br>
<br>
Pozor na běžné nástrahy. První z nich je psát zprávy v minulém čase – commit zpráva popisuje, co jste udělali, ale lépe působí rozkazovací způsob: „Přidej ošetření prázdného vstupu" místo „Přidal jsem ošetření". Druhým častým problémem je míchání více nesouvisejících změn do jednoho commitu. Pokud opravujete bug a zároveň přejmenováváte proměnnou, měly by to být dva commity. Jinak se v historii ztrácíte a nelze bezpečně vrátit jen jednu změnu.<br>
<br>
<br>
<br>
Pokud pokrytí přesáhne určitou hranici, obvykle kolem 80–90 % u kritických částí, další zvyšování vyžaduje neúměrné úsilí. Poslední chybějící řádky bývají těžko dosažitelné chybové stavy nebo edge casey, které vyžadují rozsáhlou přípravu prostředí. V tu chvíli je rozumnější investovat čas do jiných typů testů — kontraktů API, testů výkonu, nebo fuzzování vstupů. Také je vhodné sledovat, kolik chyb se najde až v produkci. Pokud produkční incidenty nesouvisí s netestovanými řádky, vaše pokrytí už neřeší reálná rizika.<br>
<br>
<br>
<br>
Až budete příště prezentovat pokrytí testy svému týmu nebo nadřízeným, přidejte k číslu vysvětlení, co přesně měří a jaká je kvalita testů. Místo „máme 85 % pokrytí" řekněte „máme 85 % řádků pokrytých testy, které prošly mutační analýzou a pravidelně chytají chyby v platebním modulu". Takový přístup je mnohem vypovídající a pomůže vám vyhnout se falešnému pocitu, že je kód bezpečný. Pamatujte, že pokrytí testy je jen jedno z mnoha měřítek kvality – a rozhodně ne to nejdůležitější.<br>
<br>
<br>
<br>
Typická chyba je měřit pokrytí globálně za celý projekt. Souhrnné číslo skryje rozdíly mezi moduly — kritická platební logika může mít 30 % pokrytí, zatímco jednoduché pomocné funkce mají 95 %. Výsledný průměr pak vypadá dobře, ale riziko zůstává. Místo toho si rozdělte kód na moduly nebo vrstvy a měřte pokrytí pro každou zvlášť. Dobré pravidlo je zaměřit se na jádro systému, které se mění nejméně, a přechody mezi moduly, kde vzniká nejvíc chyb. Sledujte trend v čase, ne jen okamžitou hodnotu — pokud pokrytí klesá, je to signál, že přibývá netestovaného kódu.