Pojďme si ukázat konkrétní případ. Máte funkci, která čte konfiguraci z globální proměnné. Napíšete test, který tuto proměnnou nastaví, a hned záhy test, který ji čte. První test projde, druhý selže, protože první test proměnnou nevrátil do původního stavu. Řešení? Použijte fixture s rozsahem function, která před každým testem nastaví výchozí hodnotu. A hlavně – nikdy neměňte globální stav napřímo v testovací funkci. Vždy to udělejte přes fixture, která se postará o úklid.
REST je vhodný, když máte jasně definované zdroje a operace nad nimi. Typicky jde o CRUD aplikace, kde každý endpoint odpovídá jedné entitě – uživatel, objednávka, produkt. Výhodou je jednoduchost a předvídatelnost. Klient ví, že GET na konkrétní adresu vrátí vždy stejnou strukturu. To usnadňuje cacheování, logování i testování. Pokud ale potřebujete data z více zdrojů najednou, REST vás nutí k několika requestům, což může zpomalit aplikaci a zkomplikovat práci klienta.
Při psaní chybového hlášení se vyvarujte obecných formulací typu „to nefunguje”. Konkrétně popište kroky, které jste provedli, a to včetně vstupních dat. Uveďte, na jakém zařízení a v jakém prohlížeči jste pracovali. Přidejte očekávaný výsledek a skutečný výsledek. Tímto způsobem prokážete, že rozumíte struktuře hlášení, což je častý požadavek i na juniorské pozice.
Co nejčastěji zkazí začátečníci a jak se tomu vyhnout Častým omylem je snaha otestovat všechno najednou. Místo toho si zvolte jednu malou oblast – třeba přihlašovací formulář – a věnujte se jí důkladně. Zkuste různé kombinace vstupů: prázdné pole, příliš dlouhý řetězec, diakritiku nebo neplatný e-mail. Zapisujte si každý test, ať už skončil úspěchem, nebo chybou. To ukáže vaši pečlivost a systematičnost.
Další pastí je přeskakování dokumentace. Mnoho začátečníků si myslí, že testovat znamená jen klikat a hledat chyby. Ale tester musí umět přečíst požadavky, porozumět tomu, jak má funkce fungovat, a pak teprve navrhnout testy. Pokud máte šanci, zkuste si najít nějaké veřejné zadání nebo si vytvořte vlastní fiktivní projekt s jasnými pravidly.
Nejlepší způsob, jak získat první praxi, je testovat vlastní projekty. Můžete si vzít jakoukoli webovou stránku, aplikaci v telefonu nebo dokonce obyčejný formulář. Projděte si ho jako běžný uživatel a hledejte chyby: nefunkční tlačítka, nejasné texty, problémy s načítáním nebo neošetřené situace, když do pole zadáte nesmysl. Každý nález si zapište – jak jste k němu došli, co jste čekali a co se stalo. Tím si vytvoříte portfolio, které ukáže vaši schopnost myslet jako tester.
Na závěr si řekněme, jak testy spouštět, aby vám nedělaly naschvály. Nikdy nespouštějte pytest z adresáře, kde máte testy i produkční kód, pokud nemáte jasně nastavenou strukturu projektů. Vytvořte si složku tests a v ní soubory s názvy jako test_*.py. Dále používejte pytest.ini nebo pyproject.toml pro konfiguraci, třeba pro nastavení cesty k testům nebo pro vypnutí varování. Tím se vyhnete situacím, kdy testy fungují jen na vašem počítači, ale v CI prostředí padají na nesprávné cestě nebo kvůli chybějícím závislostem. A až budete chtít zjistit, která část kódu není pokrytá testy, použijte nástroj pytest-cov – jen pozor na to, že pokrytí 100 % neznamená, že máte dobré testy, ale že jste pokryli všechny řádky, což je někdy víc škody než užitku.
Při posílání životopisu se zaměřte na dovednosti, ne na to, že nemáte praxi. Popište, co jste se naučili sami, jaké nástroje ovládáte a jaké projekty jste si vytvořili. Pokud máte možnost, zkuste si najít dobrovolnickou spolupráci – třeba s malou neziskovou organizací, která potřebuje otestovat svůj web. Je to reálná zkušenost, kterou můžete uvést do životopisu.
Další častá chyba se týká parametrizace. Mnoho lidí píše pro každou kombinaci vstupů zvlášť test, což vede k obrovskému množství duplicitního kódu. Místo toho použijte @pytest.mark.parametrize. Nejenže tím zkrátíte kód, ale také zpřehledníte, které kombinace selhávají. Ale pozor – parametrizace s mnoha případy může zpomalit běh. Pokud máte desítky kombinací, zvažte, jestli některé nejsou redundantní. A vždycky si pohlídejte, aby každý parametr měl čitelné ID, jinak se v hlášeních ztratíte.
Nezapomeňte, že tester bez praxe má jednu velkou výhodu – čerstvý pohled. Nejste zatížení zažitými postupy, takže můžete objevit chyby, které zkušený tester přehlédne. Buďte zvídaví, ptejte se a nebojte se dělat chyby. Každá z nich je totiž krok k tomu, abyste se stali profesionálem.
assert 1 + 1 == 2Nemusíte psát třídy ani dědit z nějaké základny – stačí funkce a assert. Tento minimalismus je hlavní výhodou oproti unittestu. Při psaní testů se vyplatí mít každý test nezávislý a zaměřený na jednu konkrétní funkcionalitu. Pokud test selže, okamžitě víte, co je rozbité
