Kdy je správný čas přidat integrační testy a kdy stačí jednotkové?
Typickou chybou je také spoléhat se na přesné porovnávání desetinných čísel. Když testujete výpočty s plovoucí řádovou čárkou, výsledek může být 2.9999999 místo 3. Místo toho použijte tolerance, třeba metodu Is.EqualTo(...).Within(0.001). Podobně si dejte pozor na porovnávání řetězců s mezerami na konci – NUnit je sice porovnává přesně, ale pokud ignorujete prázdné znaky, snadno přehlédnete chybu. Vždy používejte odpovídající constrainty a ne jenom Assert.IsTrue s podmínkou, kterou si sami napíšete.<br>
<br>
<br>
<br>
Validace vstupů a jednotné zpracování chyb jako základ stability Druhý častý problém je absence validace vstupních dat. Pokud přijímáte JSON z těla požadavku, nikdy nevíte, co přesně dorazí. Použijte knihovnu pro schémata (například Joi nebo Zod) a ověřte každý požadavek hned na začátku. Nevalidujte jen typy polí, ale i jejich povinnost a rozsahy. Pokud validace selže, vraťte odpověď se statusem 400 a jasnou chybovou hláškou. Vyhnete se tím situacím, kdy do databáze uložíte neplatná data a později zjistíte, že je musíte pracně opravovat.<br>
<br>
<br>
<br>
Při návrhu testů platí jednoduché pravidlo: nejdříve si odpovězte, co se může reálně rozbít. Pokud je riziko chyby v logice podmínek, použijte jednotkový test. Pokud je riziko v propojení s databází, souborovým systémem nebo cizí službou, integrační test je na místě. Typickou chybou je psát integrační test na všechno, co se dá, a pak trávit hodiny laděním prostředí. Druhým extrémem je jednotkové testy „nafukovat" tak, aby simulovaly vše, což vede k těžko udržovatelným mockům a testům, které neodrážejí realitu.<br>
<br>
<br>
<br>
Jakmile začnete spolupracovat s dalšími lidmi, naučte se pracovat s větvemi. Hlavní větev, často nazývaná main, by měla vždy obsahovat stabilní verzi, kterou můžete nasadit. Pro každou novou funkci vytvořte samostatnou větev, na které budete pracovat, a po dokončení ji sloučíte zpět. Konflikty při slučování jsou normální – nepanikařte. Řeší se tak, že otevřete soubory s konfliktem, ručně vyberete správné verze a pak commitnete výsledek. Častou chybou začátečníků je, že se snaží konflikt obejít tím, že přepíšou celý soubor, čímž ztratí část práce.<br>
<br>
<br>
<br>
Druhým krokem je zavedení verzování a automatizace buildu. Váš kód musí být v systému pro správu verzí, ale to nestačí. Nastavte CI (Continuous Integration), tedy automatické sestavení a spuštění testů po každém commitu. Největší chyba začátečníků je skočit rovnou na konfiguraci nástroje, aniž by si definovali, jaké testy mají běžet a co se stane, když selžou. Začněte s jednoduchým pipeline, který zkompiluje kód, spustí unit testy a postaví artefakt. Deploy zatím neřešte.<br>
<br>
<br>
<br>
Než začnete s verzováním, zkuste si nejprve nacvičit na malém projektu. Vytvořte si testovací repozitář, kde budete experimentovat s větvemi, slučováním a vracením změn. Tím získáte jistotu bez rizika, že rozbijete produkční kód. Dále si zvykněte na pravidelný commit – ideálně každou hodinu, když je práce smysluplná. Vyhnete se tak ztrátě dat a budete mít jemnou historii změn. Mějte na paměti, že verzování není jen o ukládání kopií, ale o vytváření přehledného příběhu vašeho projektu.<br>
<br>
<br>
<br>
Při prvních krocích se vyvarujte časté chyby: commitujte až příliš velké změny naráz. Místo toho rozdělte práci do logických celků. Každý commit by měl obsahovat jednu konkrétní změnu, třeba opravu chyby nebo přidání nové funkce. K tomu vždy napište výstižnou zprávu, která popisuje, co a proč jste změnili. Nikdy necommitujte tajně soubory, které obsahují hesla, API klíče nebo jiné citlivé údaje. Pro tyto případy existují soubory typu .gitignore, které určují, které soubory se nemají sledovat.<br>
<br>
<br>
<br>
Když už máte nastavený systém, naučte se efektivně využívat historii. Nezůstávejte jen u příkazů pro ukládání změn – osvojte si hledání v historii, porovnávání verzí a vracení jednotlivých souborů. To vám ušetří spoustu času při hledání, kdy se do projektu dostala chyba. Až budete mít tyto základy, můžete přejít k složitějším technikám, jako je rebasing nebo cherry-picking. Ale pamatujte, že tyto operace mění historii – pokud nepracujete sami, měňte ji jen na svých větvích, ne na sdílených.<br>
<br>
<br>
<br>
Když začnete psát jednotkové testy v C# s NUnit, první věc, kterou objevíte, je, že samotné psaní testů není to nejtěžší. Největší úskalí přichází ve chvíli, kdy se testy začnou navzájem ovlivňovat a vy ztrácíte přehled o tom, co vlastně testujete. Typická chyba začátečníků? Sdílení stavu mezi testy. Pokud použijete statickou proměnnou, která se mění v jednom testu a ovlivní výsledek druhého, přestanou být testy izolované. A izolace je základní princip, bez kterého se jednotkové testy mění v noční můru.