Proč vaše rozhraní mate uživatele, i když kód funguje

Typická chyba začátečníků je vkládat do historie soubory s přístupovými údaji, klíči nebo konfigurací pro produkci. Jakmile se takový soubor dostane do starší změny, smazání v dalším potvrzení ho z historie neodstraní. Řešením je vzorový konfigurační soubor bez hodnot a skutečné hodnoty držet mimo repozitář. Další častá chyba je vracení změn příkazem, který přepíše historii, na sdílené větvi. Přepisovat historii se smí jen tam, kam nikdo jiný neposílá.

Než napíšeš řádek kódu, napiš si větu: „Když zavolám tuto funkci s tímto vstupem, dostanu tuto hodnotu." Tato věta je jádro testu. Rozdělí se na tři části: příprava, samotné volání a ověření. Většina začátečníků přeskočí první část a rovnou volá funkci s hodnotami, které je napadnou. Jenže právě příprava rozhoduje o tom, jestli test něco ověřuje, nebo jen zaměstnává procesor.

Druhá častá chyba je příliš mnoho tvrzení v jednom testu. Když jich dáš do jednoho bloku pět, při selhání nevíš, které z nich selhalo a proč. Drž se pravidla, že jeden test ověřuje jednu věc. Název testu pak piš tak, aby popisoval očekávané chování, ne název funkce. Místo „testFunkce" použij „vrací nulu pro prázdný vstup". Za měsíc si budeš vděčný.

Pozor na asynchronní kód. Pokud v handleru použijete await a nastane výjimka, Express ji v některých verzích nezachytí. Řešením je obalovací funkce, která každý async handler obalí do Promise.resolve().catch(next), nebo použijte novější verzi Expressu s nativní podporou. Tento detail patří k nejčastějším zdrojům pádů aplikace.

Test, který nepadne, když kód rozbiješ, nic netestuje Nejčastější chyba prvního testu je, že projde vždy. Zkus to ověřit jednoduše: rozbij záměrně kód, který test pokrývá, a spusť test znovu. Pokud stále prochází, test neověřuje to, co si myslíš. Může to být tím, že porovnává nesprávné hodnoty, že používá příliš slabou podmínku, nebo že testuje jinou funkci, než zamýšlíš. Teprve když test po rozbití kódu selže, má smysl ho považovat za funkční.

Pokrytí má smysl jako trend, ne jako absolutní práh. Sleduj, jestli dlouhodobě roste u rizikových částí, a jestli klesá tam, kde se přestává testovat. Pokud číslo stagnuje, ale přibývají chyby v produkci, je něco špatně v návrhu testů, ne v jejich počtu. V takové chvíli je lepší investovat do testů integračních a do testů na úrovni chování než do dalšího zvyšování procenta. Pokrytí je nástroj, ne cíl.

Analytická fáze je plná nejistoty, protože nevíte, co se dozvíte, až začnete mluvit s lidmi. Proto ji neodhadujte jednou provždy. Udělejte hrubý odhad pro plánování kapacity a pak těsný odhad ve chvíli, kdy je úkol na řadě. Hrubý odhad stačí v řádu dnů nebo týdnů, těsný v řádu hodin. Tím se vyhnete tomu, že budete držet zastaralé číslo z doby, kdy o problému nikdo nic nevěděl.

U vstupů mysli na hraniční případy. Prázdný seznam, nula, záporné číslo, příliš dlouhý řetězec, hodnota na přesné hranici. Právě tam se chyby schovávají nejčastěji. Není potřeba pokrýt vše hned. Stačí jeden běžný případ a jeden hraniční. Tím získá první test reálnou hodnotu a ty zjistíš, jestli tvá funkce zvládá i to, co sis při psaní nepředstavoval.

První unit test nevzniká tak, že si otevřeš testovací framework a začneš psát. Vzniká ve chvíli, kdy máš jasno, co má ověřit. Vyber jednu malou funkci, která dělá jednu věc a nemá vedlejší efekty. Ideálně takovou, která vrací hodnotu na základě vstupu. Pokud sáhneš po funkci, která sahá do databáze, na síť nebo na systémový čas, první test tě naučí spíš frustraci než testování.

Většina vývojářů řeší UI až ve chvíli, kdy je logika hotová. To je první a nejčastější chyba. Rozhraní není dekorace nad databází, je to místo, kde se rozhoduje, jestli aplikace vůbec půjde používat. Pokud začnete návrhem obrazovky až po napsání endpointů, budete předělávat obojí. Začněte naopak: nakreslete na papír, co uživatel uvidí, co musí vyplnit a co se stane po odeslání. Teprve pak pište kód.

Validace a ošetření chyb jako první, ne na posled Každý vstup z těla požadavku považujte za nedůvěryhodný. Knihovny jako zod nebo joi vám umožní definovat schéma a ověřit data ještě před zápisem do databáze. Bez validace snadno vzniknou nekonzistentní záznamy, které se pak těžko opravují. Zároveň si nastavte centrální error handler – middleware se čtyřmi parametry (err, req, res, next). Když ho vynecháte, Express vrátí výchozí HTML chybovou stránku, což klient s JSONem neočekává.

Až test napíšeš, spusť ho vícekrát za sebou. Pokud výsledek kolísá, test závisí na něčem vnějším, nejčastěji na čase, náhodě nebo sdíleném stavu. To se musí odstranit, jinak bude testovat spíš infrastrukturu než logiku. Dobrý první unit test je rychlý, opakovatelný a pochopitelný i pro někoho, kdo kód vidí poprvé. Když tyto tři vlastnosti splní, můžeš ho bez obav rozšiřovat o další případy.