Pokrytí testy se obvykle měří dvěma základními metrikami, a to řádkovým pokrytím, které sleduje procento vykonaných řádků kódu, a pokrytím větví, které ověřuje, zda prošly všechny možné cesty rozhodování, jako jsou podmínky if-else. www.vyvojarska.cz praktické použití nestačí jen celkové číslo, ale vyplatí se sledovat pokrytí na úrovni jednotlivých modulů nebo tříd. Začněte tím, že si nastavíte práh, třeba osmdesát procent pro kritické části systému, a pro méně důležité utility klidně nižší. Důležité je měřit pokrytí v rámci kontinuální integrace, aby každá změna kódu ukázala rozdíl proti předchozímu stavu. Nezapomeňte také na pokrytí podmínek, kde se ověřují všechny kombinace booleanovských výrazů, protože pouhé projití řádku ještě nezaručuje, že jste otestovali všechny varianty chování. Bez této metriky snadno přehlédnete chybu v logice, která se projeví jen při specifické kombinaci vstupů.
Když už pokrytí měříte, je klíčové umět data správně interpretovat. Vysoké číslo, třeba devadesát pět procent, často vede k falešnému pocitu bezpečí, ale může být zavádějící. Pokud máte málo integračních testů a převažují unit testy, které izolovaně testují metody s nastavenými mocky, výsledné pokrytí neodráží reálnou spolupráci komponent. Zaměřte se proto na to, abyste měli dostatek testů na úrovni API a end-to-end scénářů, které procházejí celým systémem. Pokrytí vám také neřekne nic o kvalitě asercí. Můžete mít test, který zavolá metodu, ale neověří návratovou hodnotu, a přesto se počítá jako pokrytý řádek. Proto vždy kontrolujte, zda testy obsahují smysluplná očekávání, a při revizích se ptejte, zda by test skutečně selhal, kdybyste odstranili nebo změnili klíčovou logiku.
Užitečnost měření pokrytí má svůj strop, a pokud ho překročíte, začnete plýtvat časem. Hranice, kdy přestává být užitečné, je obvykle kolem osmdesáti až devadesáti procent, ale záleží na doméně a rizicích. Jakmile pokryjete všechny kritické větve a hlavní chybové stavy, další zvyšování čísla vás nutí psát testy pro triviální gettery, settery nebo okrajové větve, které se v praxi nikdy nespustí. V tu chvíli testování aplikací začíná být kontraproduktivní, protože údržba těchto testů zabere víc času než jejich přínos. Místo honby za stoprocentním pokrytím se zaměřte na rizikové části, jako je zpracování plateb, autentizace nebo synchronizace dat. Pro testování aplikací platí, že má smysl měřit pokrytí hlavně proto, abyste odhalili slepá místa, ne jako cíl sám o sobě. Pokud zjistíte, že se číslo dlouhodobě nemění a nové testy píšete jen kvůli metrice, je čas přestat měřit a věnovat energii návrhu lepších testovacích scénářů a revizi těch stávajících.
