Když psaní testů v Pythonu začíná bolet, sáhněte po pytestu

Nejdřív si ujasněte, co budete verzovat. Webový projekt obvykle obsahuje zdrojové kódy, šablony, styly, skripty a konfigurační soubory. Do verzování nepatří vygenerované soubory, jako jsou minifikované CSS nebo JavaScript, cache, nahrané obrázky ani lokální konfigurace s hesly. Pro tyto soubory si připravte seznam ignorovaných souborů hned na začátku. Pokud ho nevytvoříte, budete do historie ukládat balast, který znepřehlední každý diff a zpomalí práci s repozitářem.

Praktickým krokem je rozhodnutí o tom, co odlišuje váš projekt. Pokud jde o knihovnu, kterou mají ostatní vývojáři připojovat do svých aplikací, permisivní licence usnadní integraci. Pokud jde o samostatnou aplikaci, kterou chcete poskytovat s garancí svobody pro koncové uživatele, silnější copyleft dává smysl. Častou chybou je kombinace více licencí v jednom projektu. Přidávání souborů pod odlišnými licencemi vytváří právní zmatek a může vést k tomu, že kód nelze legálně distribuovat vůbec. Proto si hned na začátku ujasněte, jestli budete používat jednotnou licenci, nebo zda si vystačíte s výjimkou pro určité části projektu.

Pozor na jeden typický zádrhel: pokud fixture vytvoříte, ale zapomenete ho použít jako argument v testovací funkci, pytest ho nespustí. Vznikne pak chyba, která vede k domněnce, že test nefunguje. Také si dejte pozor na přílišné sdílení stavů – pokud jeden test změní data, která používá jiný test, může to způsobit nepředvídatelné selhání. Vždy proto nastavte fixtures tak, aby byly izolované a každý test začínal s čistým stavem.

Co všechno se schovává za „naprogramováním" Než začnete odhadovat, rozepište úkol na menší části a ke každé přiřaďte i tzv. skryté náklady. Patří sem čtení dokumentace, která není aktuální, hledání správného API, nastavování lokálního prostředí, nebo třeba synchronizace s kolegy na společném rozhraní. Zkuste si pro každý úkol napsat seznam činností, které nejsou na první pohled vidět, a odhadněte jim čas zvlášť. Teprve pak je přičtěte k čistému programování.

Nejdůležitější otázka zní: chcete, aby všechny odvozeniny zůstaly svobodné, nebo chcete maximální možnou adopci i za cenu, že někdo váš kód začlení do placené aplikace? Pokud je pro vás klíčová ochrana komunity a budoucích uživatelů, sáhnete po silné copyleft licenci, jako je GPL. Ta vyžaduje, aby každý, kdo distribuuje upravenou verzi, zpřístupnil zdrojový kód pod stejnou licencí. Typickou pastí je zde ale to, že GPL může odradit firmy, které chtějí knihovnu začlenit do interního systému, aniž by musely otevírat vlastní kód.

Častou chybou je odhadovat pouze podle „čistého" času, který byste potřebovali, kdyby vše proběhlo hladce. Realita ale vypadá jinak. Přidejte rezervu na hledání chyb, na nejasné požadavky a na komunikaci. Zkušení vývojáři často používají pravidlo, že k hrubému odhadu přidají 30–50 % času na skryté činnosti. Není to univerzální vzorec, ale dobrý startovní bod, který pak upravíte podle konkrétního projektu.

Při odhadu myslete i na to, že ne vždy budete pracovat v nepřerušovaném bloku. Schůzky, e-maily nebo dotazy kolegů rozbíjejí koncentraci a každé přerušení vás stojí čas na opětovné ponoření do problému. Pokud víte, že máte den plný schůzek, neplánujte si na ten den úkol, který vyžaduje hluboké soustředění. Místo toho si rezervujte časové bloky, které jsou vyhrazeny pouze pro práci bez rušení.

Na závěr si uvědomte, že i bez integračního prostředí můžete dosáhnout vysoké pokrytí testy. Klíčem je oddělit čistou logiku od side efektů a testovat každou část izolovaně. Tím získáte rychlé a spolehlivé testy, které vám dají jistotu, že vaše reducery a async akce fungují správně, a to bez složitého nastavování prostředí. Až příště přidáte novou akci nebo upravíte reducer, budete moci okamžitě ověřit, že nic nerozbijete – a to je k nezaplacení.

Vyplatí se ale dávat pozor na jeden častý omyl: váš testovací soubor do aktuálního adresáře. Pokud testujete funkci z modulu, musíte mít správně nastavený import. Nejjednodušší je spouštět pytest z kořenového adresáře projektu, kde máte balíčky i testy. Místo from moje_aplikace import funkce občas selhává kvůli špatné struktuře složek. Řešením je buď použít relativní importy, nebo přidat do kořene projektu soubor pyproject.toml s nastavením pythonpath. Tento krok ušetří hodiny hledání chyb, které ve skutečnosti nejsou chybami kódu.

Pokud chcete jít ještě dál, můžete si vytvořit jednoduchý pomocný „test store", který bude mít dispatch a getState, ale nebude obsahovat middleware. To vám umožní testovat i kombinace reducerů a async akcí dohromady, ale stále bez nutnosti spouštět celou aplikaci. Tento přístup je užitečný pro ověření, že akce správně mění stav napříč více reducery. Stačí, když si definujete výchozí stav celého store, zavoláte async akci s tímto store a poté zkontrolujete, jak se stav změnil.