Editing Pytest, který tiše prochází: past s příliš obecnými asertacemi

Základem je pochopit, jak pytest sbírá testy. Hledá soubory pojmenované test_*.py nebo *_test.py a v nich funkce začínající na test_. Pokud soubor nebo funkci pojmenuješ jinak, pytest je přeskočí a ty budeš marně hledat, proč se testy nespouštět. Třídy musí začínat na Test a nesmí mít vlastní __init__. To je první místo, kde se ztrácí čas.<br><br>Lidé jsou třetí a největší překážka. Pokud provozní tým cítí, že mu vývojáři předávají nehotovou práci, a vývojáři zase, že je provoz brzdí, žádná automatizace to nespraví. Pomáhá společné vlastnictví služby, společné pohotovosti a to, že se incidenty rozebírají bez hledání viníka. Chyby se mají zapisovat a opravovat v systému, ne v lidech. Teprve když obě strany vidí stejná data a mají stejný cíl, začne DevOps dávat smysl.<br><br>U pohovoru nepředstírej zkušenosti, které nemáš. Mnohem lépe působí, když řekneš, že praxi nemáš, ale tento konkrétní projekt jsi otestoval a našel tyto chyby. Připrav si odpovědi na otázky typu: jak bys otestoval přihlášení, co uděláš, když vývojář tvrdí, že chyba není reprodukovatelná, jak rozhodneš, kterou chybu hlásit první. Pokud umíš odpovědět věcně, tvá chybějící praxe přestane být hlavní téma.<br><br>Kód, který funguje, ještě nemusí být kód, který se dá číst. Rozdíl mezi oběma bývá vidět až ve chvíli, kdy se k souboru vrátíš po půl roce nebo do něj vstoupí kolega. Čistý kód v JavaScriptu není o estetice. Je to praktická vlastnost: zkracuje dobu, za kterou najdeš chybu, a snižuje riziko, že při opravě rozbiješ něco jiného.<br><br>Než začnete stavět aplikaci na konkrétní databázi, je nutné zjistit, co vlastně znamená slovo „podpora". Nejde jen o to, zda databáze existuje, ale zda podporuje datové typy, transakce, indexy, replikaci a způsob dotazování, který budete potřebovat. Mnoho projektů selhalo ve chvíli, kdy se vývojář spolehl na obecný seznam funkcí a přehlédl, že jeho konkrétní verze nebo konfigurace danou vlastnost neumí. Ověřování proto začněte u svého datového modelu: sepněte si, jaká data budete ukládat, jaké dotazy budete psát a jaké operace musí být atomické. Teprve pak hledejte, zda to databáze zvládne.<br><br>Před otevřením požadavku na sloučení si větev aktualizujte vůči hlavní. Můžete zvolit rebase, tedy přenesení vlastních commitů na aktuální špičku hlavní větve. Rebase dělá historii čistou, ale nikdy ho nedělejte na větvi, kterou už někdo jiný stáhl k sobě. Přepíšete tím commity, které má kolega u sebe, a vznikne zmatek. Pokud si nejste jistí, použijte raději sloučení pomocí merge commitu. Je to bezpečnější a v týmu s menšími zkušenostmi s rebasem i srozumitelnější.<br><br>Posledním častým omylem je ignorování parametrizace. Místo kopírování stejného testu s různými vstupy použij @pytest.mark.parametrize. Ušetříš řádky a zpřehledníš výstup. Pokud test spadne, pytest ukáže konkrétní kombinaci parametrů. Bez parametrizace se v chybovém výpisu ztratí, který případ selhal. A to je přesně ten okamžik, kdy testování přestává být užitečné a stává se jen dalším zdrojem zmatku.<br><br>Fixtury a izolace: kde vzniká většina falešných výsledků Fixtury v pytestu řeší přípravu dat a úklid po testu. Dekorátor @pytest.fixture umožní předat testovací funkci připravený objekt. Pokud ale fixture vytváří data na úrovni modulu a test je mění, ovlivní to ostatní testy. Výchozí rozsah je function, což je bezpečné. Změna na module nebo session zrychluje běh, ale vyžaduje, aby testy data pouze četly, ne přepisovaly. Kdo to nedodrží, dostane testy, které procházejí v jednom pořadí a padají v jiném.<br><br>Další pastí je testování závislostí na vnějším světě. Volání sítě, databáze nebo systémového času v testu znamená, že výsledek závisí na prostředí. Řešením je nahradit tyto závislosti pomocí monkeypatch nebo fixtur, které vrací předvídatelné hodnoty. Pytest nabízí monkeypatch.setattr pro dočasnou výměnu atributů a monkeypatch.setenv pro proměnné prostředí. Po skončení testu se vše vrátí zpět. Bez toho se testy stávají křehkými a jejich výsledek neříká nic o kvalitě kódu.<br><br>Pytest je dnes nejrozšířenější testovací rámec v Pythonu a většina vývojářů ho používá intuitivně. Právě v tom spočívá problém. Napsat test, který proběhne zeleně, je snadné. Napsat test, který skutečně ověří, co má, a spadne ve chvíli, kdy kód přestane fungovat, je dovednost. Mnoho začátečníků skončí u testů, které jen kontrolují, že se funkce zavolala bez výjimky, a tím si vytvoří falešný pocit jistoty.<br><br>Samotné asertace jsou dalším častým zdrojem problémů. Místo assert vysledek == True piš assert vysledek. Místo porovnávání celých řetězců kontroluj konkrétní hodnoty. Pytest umí srozumitelně vypsat, co se rozchází, ale jen když mu dáš přesnou informaci. Asertace typu assert len(seznam) >0 neověří, že seznam obsahuje očekávané prvky, pouze že není prázdný. Test pak prochází i ve chvíli, kdy funkce vrací nesmyslná data.