Automatizace testů na CI serveru, kterou zabíjí špatně nastavený cache

Základní tvrzení obstará obyčejný assert. Žádné assertEqual, assertTrue a podobné metody. Když test selže, pytest sám zobrazí hodnoty obou stran výrazu, takže není potřeba psát vlastní chybové zprávy. Pozor na jeden častý omyl: do testů nepatří volání print pro ladění. Mnohem lepší je spustit pytest s přepínačem -s, který výstup nezachytává, nebo použít --pdb, jenž při chybě otevře interaktivní debugger přímo v místě selhání.
Odhad není smlouva. Je to nástroj pro rozhodování. Když se změní zadání, musí se změnit i odhad. Když se objeví nová informace, je normální ho upravit. Tým, který se drží zastaralého čísla jen proto, že bylo řečeno nahlas, dokončení interiéru nakonec dodá něco jiného, než bylo potřeba. Zdravý přístup je odhadovat průběžně, mluvit o nejistotě otevřeně a mít rezervu na věci, které nikdo nečekal.

První praktický krok je změřit, kolik testů z které vrstvy skutečně běží proti sdílené databázi. Většina týmů zjistí, že unit testy jsou jen formální a integrační vrstva je ve skutečnosti ta nejtlustší. To je opačný tvar než pyramida. Bez tohoto měření se bude debata o architektuře testů točit v kruzích.

Izolace dat místo izolace prostředí Řešení není postavit každému týmu vlastní databázi. To jen přesune problém k infrastruktuře a provozním nákladům. Funguje něco jiného: každý test si připraví vlastní datový prostor a po sobě ho uklidí. V praxi to znamená transakci, kterou test na konci roluje zpět, nebo dočasné schéma vytvořené pro daný běh. Testy tak mohou běžet paralelně, aniž by si navzájem přepisovaly řádky.

Pozor na dva typické omyly. První je spoléhání na to, If you beloved this article and you would like to acquire a lot more data about návod najdete zde kindly pay a visit to the web site. že se testy „nějak domluví" přes pořadí spouštění. Jakmile přibude tým nebo se změní pipeline, pořadí se rozpadne a testy začnou padat náhodně. Druhý omyl je mazání celé tabulky mezi testy. To funguje, dokud jsou týmy dva. Při pěti týmech se běhy překrývají a jeden maže data druhému pod rukama.

Ukládání je třetí místo, kde se chyby hromadí. Dynamicky rostoucí diskový soubor se při každém zápisu zvětšuje a fragmentuje. Po měsících provozu zabírá víc místa, než kolik dat skutečně obsahuje, a zápis se zpomaluje. Řešení je buď pravidelná komprimace, nebo předalokovaný pevný disk. Pozor ale na snapshoty — každý další se řetězí a při jejich velkém počtu se čtení disku výrazně zpomalí. Před sloučením snapshotů je nutné mít dostatek volného místa, jinak operace selže a stroj zůstane v nekonzistentním stavu.

Logy musí být čitelné. Pokud test selže, výstup má obsahovat přesný příkaz, návratový kód a relevantní část logu. Nezahlcujte CI celým výstupem, ale nechte možnost stáhnout artefakty. Testy, které závisí na čase nebo náhodě, nastavte tak, aby používaly pevné datum a seed. Opakované spouštění stejného commitu musí dát stejný výsledek, jinak automatizace ztrácí smysl.

Poslední oblastí jsou aktualizace. Aktualizace hostitelského systému může změnit verzi hypervizoru a starší virtuální stroje pak nenaběhnou kvůli nekompatibilnímu formátu uloženého stavu. Před každou větší aktualizací je proto vhodné stroje řádně vypnout, ne jen pozastavit, a zálohovat konfigurační soubory. Pokud se stroj přesto nespustí, pomůže odebrat uložený stav a nastartovat načisto — přijdete o rozpracovanou session, ale ne o data na disku.

Druhá věc, kterou je potřeba oddělit, jsou datové kontrakty. Sdílená databáze znamená, že každý tým vidí schéma ostatních. Když jeden tým přidá sloupec nebo změní význam pole, testy ostatních týmů mohou tiše přestat ověřovat to, co mají. Zavede se proto pravidlo, že změna schématu prochází stejným review jako změna veřejného rozhraní. V commit zprávě musí být uvedeno, které týmy to ovlivní.

Cache je největší past, na kterou se zapomíná Zrychlení pipeline pomocí cache závislostí je užitečné, ale jen když klíč cache odpovídá skutečnému obsahu. Pokud klíč tvoříte jen z názvu větve, po změně lockfile dostanete staré balíčky a testy poběží proti něčemu jinému, než co je v repozitáři. Klíč sestavte z hashe lockfile a verze nástroje. Stejně tak cache pro build výstup: pokud ji nesvážete s konkrétním commitem, může pipeline použít zastaralý artefakt a testy projdou, i když kód nefunguje.

Poslední praktická rada se týká poměru vrstev. Cílem není dostat se na nějaké ideální číslo, ale zastavit růst end-to-end testů. Každý nový scénář na úrovni celé aplikace by měl mít zdůvodnění, proč ho nelze ověřit na nižší vrstvě. Když se tento zvyk zavede, pyramida se postupně narovná sama, aniž by někdo musel nařizovat shora, kolik testů smí který tým napsat.