První kroky s Pythonem pro automatizaci úloh

Než napíšete první unit test, zapomeňte na představu, že testy jsou něco navíc. Jsou to spustitelné dokumentace vašeho kódu. Začněte u malé, izolované funkce, která nemá vedlejší účinky. Ideální je čistá funkce, která přijímá vstup a vrací výstup. Vyhněte se psaní testů pro třídy s databází, souborovým systémem nebo síťovými voláními. To je integrační testování a na to budete potřebovat jiné nástroje.

Klíčové je rozlišovat mezi „co" a „proč". Diff vám ukáže, co se změnilo, ale ne proč. Proto v popisu vždy vysvětlete důvod. Například místo „Změněna barva tlačítka" napište „Změněna barva tlačítka na tmavší, aby byl lépe viditelný na světlém pozadí". Taková informace šetří čas při revizi kódu i při budoucí údržbě. Pokud je změna složitější, rozdělte ji do více commitů, ať každý dělá jednu věc. To usnadní reverz a hledání příčiny chyb.

Důležité je nepřehánět mockování. Pokud mockujete každou závislost, testy se stanou křehkými a přestanou odrážet realitu. Na druhou stranu příliš mnoho integračních testů s reálnou infrastrukturou (databáze, fronty) zpomaluje lokální vývoj i CI pipeline. Najděte kompromis: pro běžné operace použijte in-memory varianty úložišť, ale pro kritické transakce nechte běžet test proti skutečné databázi (například v Dockeru). Tím získáte rychlost i věrohodnost.

Častou chybou je psát zprávy v minulém čase, jako byste popisovali hotovou věc. Lepší je použít rozkazovací způsob nebo přítomný čas, protože to odpovídá tomu, co commit dělá, když je aplikován. Například „Přidej testy pro přihlášení" je jasné a akční. Vyhněte se také vágním slovům jako „úpravy", „oprava" nebo „refaktoring" – pokud neřeknou, co konkrétně je upraveno, opraveno nebo refaktorováno. Vždy doplňte, co je předmětem změny, ať už jde o soubor, funkci nebo chování.

Nejdůležitější částí testu není samotný kód, ale to, co testujete. Zaměřte se na hraniční případy: co se stane, když funkce dostane nulu, záporné číslo, prázdný řetězec nebo null? Právě tam se nejčastěji skrývají chyby. Napište tři testy pro jednu funkci: jeden pro běžný vstup, jeden pro hraniční hodnotu a jeden pro neočekávaný vstup. Tím zajistíte, že váš kód nefunguje jen pro příklad z tutoriálu, ale i v reálném nasazení.

Na závěr: testy nejsou cíl, ale prostředek. Cílem je spolehlivý software, který lze bez obav měnit. Proto pravidelně revidujte svou testovací sadu a ptejte se, zda každý test přináší hodnotu. Pokud ne, smažte jej. To je někdy těžké, ale je to nezbytné pro dlouhodobou udržitelnost projektu.

Růst codebase s sebou nese tlak na rychlost dodávání nových funkcí. Často se ale zapomíná na to, že testy nejsou jen pojistka proti regresím, ale i nástroj, který ovlivňuje rychlost vývoje. Klíčové je najít rovnováhu mezi jednotkovými testy, které testují izolované části kódu, a integračními testy, které ověřují spolupráci komponent. Pokud je poměr špatně, údržba testů začne požírat čas, který by mohl jít do produktu.

Poté přejděte do složky, kterou chcete verzovat, a spusťte příkaz git init. Tím vytvoříte skrytou složku .git, která obsahuje celou historii projektu. Nyní můžete začít sledovat soubory. Příkaz git add . přidá všechny soubory do takzvané „staging area" – dočasného prostoru, kde se připravují změny pro commit. Pokud chcete přidat jen konkrétní soubor, použijte git add soubor.txt. Častou chybou je zapomenout na tento krok a rovnou spustit commit, což vede k tomu, že se změny neuloží.

Když procházíte historii projektu, každá commit zpráva by měla odpovědět na dvě otázky: co se změnilo a proč. Většina vývojářů ale píše zprávy jako „oprava bugu" nebo „úpravy". Takové popisy jsou k ničemu, protože neříkají, co přesně se dělo, a hlavně proč. Bez kontextu se po pár měsících vracíte k hádankám a musíte ručně procházet diff, abyste zjistili, co se vlastně stalo. Cílem není psát romány, ale dodat dostatek informací, aby se kdokoli v historii rychle zorientoval.

Začněte tím, že si pečlivě naplánujete testovací scénáře. Nezapomeňte na okrajové případy, jako je přerušení připojení, příchod notifikace nebo volání během používání aplikace. Typickou chybou je testovat pouze na nejnovějším zařízení s nejnovější verzí systému. V praxi se ale většina uživatelů pohybuje na starších modelech, a proto je důležité mít k dispozici zařízení s různými verzemi operačního systému, nebo využít cloudové služby pro testování na vzdálených zařízeních.

Na závěr si osvojte zvyk commitovat často a s jasnými zprávami. Nemusíte čekat, až bude funkce hotová – každý logický krok si zaslouží commit. Také se naučte číst výstupy příkazů, protože Git vás často upozorní na chyby nebo vám poradí, co dělat dál. S těmito základy budete schopni bezpečně verzovat své projekty a snadno se v historii zorientujete.