Jak začít s pytestem a psát testy, které dávají smysl

Další pastí je verzování samotného kódu podle data, nikoliv podle sémantické verze. Pokud přidáváte nové funkce, ale zároveň měníte staré, zvyšte major verzi. Pokud jen opravujete chyby, zvyšte minor verzi. Pokud měníte jen interní detaily, zvyšte patch. Toto pravidlo musí být napsané v dokumentaci projektu a každý člen týmu ho musí dodržovat. Bez toho se rychle stane, že dvě verze knihovny mají stejné číslo, ale různé chování, což je nejhorší možný scénář.

Základní struktura projektu je jednoduchá: testy umístěte do adresáře tests a pojmenujte soubory test_nazev.py. Spuštění probíhá příkazem pytest v kořenovém adresáři. Pytest automaticky sbírá soubory začínající na test_ a funkce v nich. Pro první test stačí napsat funkci s assert, která porovná očekávaný výsledek se skutečným. Pokud test selže, pytest vypíše podrobné informace o tom, co se neshoduje, takže chybu rychle najdete.

Typické chyby a prevence Nejčastější chybou je spoléhání na „nejnovější dostupnou verzi". To vede k tomu, že se build chová odlišně na různých počítačích, protože prostředí stáhne pokaždé jinou verzi. Řešením je soubor zámků, který zaznamená přesnou verzi každé knihovny a také hash jejího zdroje. Tento soubor musí být commitnutý a nesmí se měnit ručně. Druhou častou chybou je aktualizace knihovny, která mění chování v jiné části projektu, aniž by to byl reflektováno v testech. Proto si před aktualizací spusťte celou testovací sadu a porovnejte výstup před a po změně.

První commit: od návrhu k přijetí Než začnete psát kód, založte si vlastní větev (fork) a v ní vytvořte samostatnou větev pro vaši změnu. Postupujte podle pokynů v dokumentaci – pokud tam není řečeno nic jiného, držte se stylu kódu, který už v projektu existuje. Napište testy pro novou funkci a ověřte, že všechny stávající testy procházejí. Commitové zprávy pište stručně a výstižně – popište, co děláte a proč, ne kopírujte celou diskuzi z issue. Po odeslání pull requestu se připravte na to, že maintaineři mohou požadovat úpravy. To je normální součást procesu, neznamená to, že vaše práce je špatná.

Nakonec pamatujte, že verzování není jen o číslech, ale o komunikaci. Nezavádějte příliš mnoho verzí najednou. Pokud je to možné, udržujte jednu hlavní verzi knihovny a pro starší verze vytvářejte jen bezpečnostní opravy. U projektů s více verzemi knihoven pak vždy definujte, která verze je oficiální pro produkci a která je určena pro experimenty. Tím se vyhnete zmatkům a všichni budou vědět, na čem staví.

Poslední rada: sledujte metriky, ale ne ty povrchní. Nesledujte jen, kolik nasazení proběhne za týden. Sledujte, jak rychle se daří obnovit službu po výpadku, jak dlouho trvá projít od změny kódu po produkci a jak často dochází k selhání nasazení. Tyto ukazatele vám řeknou víc než počet automatizovaných testů. Až budete mít vše stabilní, můžete postupně rozšiřovat rozsah – přidávat další prostředí, další týmy a další automatizaci.

Dalším krokem je zavedení průběžné integrace a doručování. V praxi to znamená, že každá změna v kódu se automaticky sestaví, otestuje a připraví k nasazení. K tomu stačí jednoduchý nástroj, který spustí testy a v případě úspěchu nasadí aplikaci na testovací prostředí. Na začátku se vyhněte složitým pipeline s mnoha fázemi a mnoha prostředími. Lepší je jednoduchý řetězec, který funguje spolehlivě, než složitý, který se často rozbíjí.

Postup převodu schématu a dat Pro převod schématu použijte nástroj jako pgloader nebo ruční skript. Pokud migrujete ručně, začněte vytvořením databáze v PostgreSQL a postupně vytvářejte tabulky. Nahraďte AUTO_INCREMENT za SERIAL nebo GENERATED AS IDENTITY, upravte ENUM na CREATE TYPE, a převeďte datumové a časové typy podle potřeby. Následně exportujte data z MySQL do CSV nebo SQL souboru a importujte je pomocí COPY nebo psql. Vždy před importem vypněte kontroly cizích klíčů, abyste předešli chybám pořadí.

První kroky: automatizace a verze Začněte s automatizací opakovaných úkonů. Nejdřív zmapujte, jak probíhá nasazení aplikace dnes. Pokud se dělá ručně pomocí příkazů na serveru, zapište všechny kroky do skriptu. Tento skript pak uložte do verzovacího systému a postupně ho vylepšujte. Stejně tak začněte verzovat konfigurace a infrastrukturu – popis prostředí by měl být v kódu, ne v dokumentu. Tím získáte možnost kdykoli reprodukovat stejné prostředí pro testování i produkci.

Prvním krokem je určit si, které funkce jsou pro vás klíčové. Pokud jste začátečník, potřebujete hlavně zvýraznění syntaxe, jednoduché spouštění kódu a rychlé odhalení chyb. Naopak pokud pracujete na větším projektu, oceníte integrovaný debugger, podporu verzovacích systémů a automatické dokončování kódu. Dejte si pozor na přehnané množství pluginů – každá instalace navíc zvyšuje nároky na výkon a může zpomalit prostředí. Začněte s čistou instalací a přidávejte jen to, co opravdu využijete.