Pytest a unittest: co zvolit pro testování v Pythonu

Častou chybou je spoléhat na to, že podpora vyřeší všechny problémy, aniž byste se podíleli na diagnostice. Připravte si vždy relevantní informace – výpis z logů, popis kroku, který problém vyvolal, a případně i ukázku dat, na kterých chyba nastává. Čím přesnější informace poskytnete, tím rychlejší a užitečnější odpověď dostanete. Vyvarujte se také tomu, abyste podporu kontaktovali s dotazem, který je jasně popsán v dokumentaci – to jen zdržuje vás i podporu a může to vést k tomu, že se na vaše další, závažnější dotazy bude reagovat pomaleji.

Pokrytí přestává být užitečné ve chvíli, kdy se stane cílem samo o sobě. Když tým diskutuje o tom, jak zvýšit procento z 85 na 90, místo aby řešil, které rizikové části kódu nejsou otestované, je to varovný signál. Stejně tak když je pokrytí používáno jako jediné kritérium pro schválení pull requestu, vede to k formálním úpravám, které nemají vliv na spolehlivost. Místo honění čísel se zaměřte na testování kritických a často měněných částí. Pokud máte systém s mnoha vnějšími závislostmi, pokrytí řádků u integračních testů vypovídá málo o tom, jestli je spolupráce komponent správná.

Při zavádění nové databáze nebo při změně poskytovatele podpory si dopředu nastavte jasné komunikační kanály. Ideální je mít jednu kontaktní osobu, která má přehled o vašem prostředí a může rychle rozhodovat o prioritách. Zároveň si uložte všechny důležité informace o přístupech, heslech a konfiguracích na bezpečné místo, ke kterému má přístup více členů týmu. Tím se vyhnete situaci, kdy je jediný administrátor na dovolené a nikdo jiný neví, jak databázi spravovat. Podpora databáze není jen o tom, že máte telefonní číslo na helpdesk – je to systém opatření, který vám umožní udržet provoz stabilní i v krizových situacích.

Na závěr si řekněme, jak testy spouštět, aby vám nedělaly naschvály. Nikdy nespouštějte pytest z adresáře, kde máte testy i produkční kód, pokud nemáte jasně nastavenou strukturu projektů. Vytvořte si složku tests a v ní soubory s názvy jako test_*.py. Dále používejte pytest.ini nebo pyproject.toml pro konfiguraci, třeba pro nastavení cesty k testům nebo pro vypnutí varování. Tím se vyhnete situacím, kdy testy fungují jen na vašem počítači, ale v CI prostředí padají na nesprávné cestě nebo kvůli chybějícím závislostem. A až budete chtít zjistit, která část kódu není pokrytá testy, použijte nástroj pytest-cov – jen pozor na to, že pokrytí 100 % neznamená, že máte dobré testy, ale že jste pokryli všechny řádky, což je někdy víc škody než užitku.

Testování je nedílnou součástí vývoje, a pokud pracujete v Pythonu, pytest je jedním z nejpoužívanějších nástrojů. Na rozdíl od standardního unittestu nabízí jednodušší syntaxi, méně kódu a bohaté možnosti rozšíření. V tomto článku se zaměříme na praktické základy – od psaní prvních testů až po typické chyby, kterým se vyhnout.

Další častá chyba se týká parametrizace. Mnoho lidí píše pro každou kombinaci vstupů zvlášť test, což vede k obrovskému množství duplicitního kódu. Místo toho použijte @pytest.mark.parametrize. Nejenže tím zkrátíte kód, ale také zpřehledníte, které kombinace selhávají. Ale pozor – parametrizace s mnoha případy může zpomalit běh. Pokud máte desítky kombinací, zvažte, jestli některé nejsou redundantní. A vždycky si pohlídejte, aby každý parametr měl čitelné ID, jinak se v hlášeních ztratíte.

Základním krokem je vybrat správný typ pokrytí. Nejčastěji se setkáte s pokrytím řádků, které je snadné spočítat a snadno se prezentuje. Větší výpovědní hodnotu má pokrytí větví, protože odhaluje, jestli byly testovány obě možnosti u podmínek, a pokrytí podmínek, které kontroluje jednotlivé logické výrazy. Pro nový kód si nastavte cíl alespoň pro pokrytí větví; jen řádky vás nechají ve slepé uličce, protože můžete mít 80 % řádků a přitom polovinu rozhodovacích cest netestovanou. Důležité je měřit pokrytí na úrovni jednotek, nikoli jen na úrovni celého systému, a výsledky ukládat do historie, abyste viděli trend.

Praktickým přístupem je kombinovat měření pokrytí s analýzou mutací, která do kódu záměrně vnáší chyby a kontroluje, jestli je testy odhalí. Taková zpětná vazba je mnohem cennější než samotné procento. Udržujte pokrytí jako orientační ukazatel, ne jako dogma. Pro nový kód si nastavte rozumný minimální limit, ale u staršího kódu ho nezvyšujte násilně. Místo toho postupně doplňujte testy tam, kde dochází k nejčastějším chybám nebo kde je složitá logika. A nezapomeňte, že pokrytí nic neříká o tom, zda testy běží rychle a spolehlivě. Pomalé a flaky testy, které občas selžou bez zjevné příčiny, snižují důvěru v celou sadu, i když pokrytí ukazuje vysoká čísla.