Na co si dát pozor: testy nesmí záviset na pořadí ani na datech, která zůstala z předchozího běhu. Pokud test zapisuje do souboru nebo do databáze, musí po sobě uklidit, jinak druhý běh selže z nesouvisejícího důvodu. Dále se vyhni volání skutečné sítě a externích služeb – nahraď je pomocí monkeypatch nebo jednoduchých fake objektů. Test, který padá kvůli výpadku cizí služby, přestane lidi bavit. A když test selže, nespravuj rovnou kód – nejdřív si přečti výpis, protože často je chyba v očekávané hodnotě, ne v logice.

Na co se vyplatí dát pozor při testování Než se rozhodnete, vyzkoušejte dvě až tři možnosti na skutečném projektu, ne na cvičném souboru. Otevřete v nich složku s více soubory, spusťte testy a zkuste přejmenovat proměnnou napříč projektem. Sledujte, jak rychle editor reaguje na velký soubor a zda zvládá type hints. Pokud používáte Jupyter notebooky, ověřte, že editor umí buňky spouštět a zobrazovat výstupy. U webových projektů se hodí integrace s linterem a formátovačem. Nastavte je tak, aby formátovaly při uložení. Pozor na konflikty pravidel: pokud linter zakáže něco, co formátovač vrací zpět, vývoj se zpomalí.

Asynchronní kód je místo, kde se čistota láme nejčastěji. Místo řetězení .then() a .catch() používejte async/await a obalte volání do try/catch. Nikdy nezapomeňte na await u funkce, která vrací promise. Typická chyba je, že zapomenete await a pak se divíte, proč máte v proměnné promise místo dat. Stejně tak nedávejte await do cyklu for, pokud nechcete čekat postupně. Když potřebujete paralelní zpracování, použijte Promise.all.

Základ je jednoduchý: soubor pojmenovaný test_*.py nebo *_test.py, v něm funkce začínající test_. pytest si je najde sám. Funkce obvykle nebere žádné argumenty, uvnitř zavolá testovaný kód a výsledek ověří pomocí prostého assert. Když assert selže, pytest vypíše přesně, co bylo vlevo, co vpravo a kde k chybě došlo. To je hlavní výhoda proti ručnímu if a print.

Refaktorování často skončí jako ruční přepisování, při kterém se snadno zapomene na okrajové případy. Přitom většina moderních IDE nabízí nástroje, které stejnou práci zvládnou rychleji a bezpečněji. Klíčem je vědět, které funkce použít a kdy. Nejde o hromadné přejmenování všeho, co najdete, ale o cílené zásahy s okamžitou kontrolou.

U rozsáhlých projektů oceníte indexaci celého repozitáře. Ta ale spotřebovává paměť. Pokud máte méně RAM, vypněte indexaci nepotřebných složek, jako jsou virtuální prostředí nebo stažené balíčky. Další častá chyba je ignorování nastavení projektu. Konfiguraci ukládejte do složky projektu, ne do globálního nastavení. Kolegové tak dostanou stejné podmínky. U týmové práce se vyplatí verzovat konfiguraci editoru a nedávat do ní absolutní cesty.

U dávkového vkládání a hromadných aktualizací se často objevuje jiná chyba: aplikace spojí více hodnot do jednoho dotazu a zapomene, že počet parametrů musí odpovídat počtu zástupných symbolů. Pokud se počet neshoduje, vývojář sáhne po ručním skládání a tím vrátí injektáž zpět do hry. Bezpečnější je zpracovat dávku po menších částech nebo použít jeden připravený dotaz v cyklu, i za cenu mírně vyšší režie.

Základem je přejmenování symbolů. Místo ručního hledání a nahrazování použijte funkci Rename (obvykle klávesa F2 nebo Shift+F6). IDE přejmenuje pouze skutečné výskyty v rámci rozsahu, ne řetězce v komentářích nebo v jiných modulech. Před spuštěním zkontrolujte náhled změn, který IDE zobrazí. Typická chyba: přejmenování přes prosté Find and Replace, které přepíše i texty v dokumentaci a rozbije cizí kód.

Změna signatury metody je další častý refaktoring. Použijte Change Signature, kde přidáte, odeberete nebo přeuspořádáte parametry. IDE upraví všechna volání, včetně těch v testech. Pozor na výchozí hodnoty a přetížené metody: náhled změn vždy projděte, protože automatické úpravy nemusí odpovídat zamýšlenému chování. Pokud si nejste jistí, udělejte změnu po menších krocích a po každém spusťte testy.

Na závěr: začni jedním testem pro funkci, kterou právě píšeš. Spusť ho, uvidíš červenou, oprav kód, uvidíš zelenou. Teprve pak přidej další. pytest není něco, co se nasazuje na hotový projekt; je to nástroj, který mění způsob, jakým o kódu přemýšlíš během psaní.

První měsíce nejsou o výkonu, ale o zvyku. Nastav si rutinu: ráno si přečti, co se změnilo v repozitáři, odpoledne si zapiš, čemu nerozumíš. Každý den pošli alespoň jednu otázku do týmového kanálu. Neptej se „jak to funguje", ale „vidím tady volání téhle funkce, chápu správně, že vrací seznam?" Konkrétní otázka ukazuje, že jsi kód četl. Obecná otázka ukazuje, že jsi ho neotevřel.