Rychlé unit testy, nebo pomale E2E: kde je hranice

Základ tvoří unit testy. Testují jednu funkci, jednu třídu nebo jeden malý modul bez databáze, sítě a souborového systému. Musí běžet v milisekundách, jinak je vývojáři přestanou spouštět. Pište je na logiku, výpočty, validace a větvení. Naopak netestujte gettery, settery a triviální delegování. Častá chyba je mockování všeho, co jde — výsledkem je test, který ověřuje implementaci, ne chování. Když se změní vnitřní struktura, test spadne, i když aplikace funguje správně.

Kde se nejčastěji chybuje a jak se tomu vyhno

Požadavek na sloučení nemá být formalita. Napište do něj, co změna řeší, jak jste ji otestovali a na co si dát pozor. Recenzent nemá hádat záměr z deseti commitů. Když je změna velká, rozdělte ji na několik menších požadavků. Malé změny se kontrolují rychleji a snáze se vracejí, pokud se něco pokazí. Nikdy neschvalujte vlastní změnu jen proto, že spěcháte.

Typická chyba je snaha izolovat všechno. Mockovat databázi, HTTP klienta i čas najednou vede k testům, které ověřují mocky, ne kód. U integračních testů je lepší použít skutečnou databázi osvětlení v obýváku kontejneru nebo lehkou instanci a připravit data před každým testem. Pokud test závisí na datech z produkce, je křehký a nikdo mu nebude věřit.

Základem obrany je používat parametrizované dotazy nebo prepared statements. Databázový ovladač pošle strukturu dotazu zvlášť a hodnoty zvlášť, takže vstup nikdy nezmění syntaxi příkazu. V praxi to znamená, že místo skládání řetězce s proměnnou uvnitř dotazu předáte hodnotu jako vázaný parametr. Tento přístup podporuje většina moderních knihoven a frameworků. Pokud používáte ORM, ověřte, že i přímé dotazy v něm jsou parametrizované, protože některé metody umožňují vložit surový řetězec.

U pohovoru nepředstírej zkušenosti, které nemáš. Mnohem lépe působí, když řekneš, že praxi nemáš, ale tento konkrétní projekt jsi otestoval a našel tyto chyby. Připrav si odpovědi na otázky typu: jak bys otestoval přihlášení, co uděláš, když vývojář tvrdí, že chyba není reprodukovatelná, jak rozhodneš, kterou chybu hlásit první. Pokud umíš odpovědět věcně, tvá chybějící praxe přestane být hlavní téma.

End-to-end testy jdou celou cestou od uživatelského rozhraní po databázi. Jsou nejdražší a nejkřehčí. Patří sem jen klíčové scénáře: přihlášení, dokončení objednávky, uložení formuláře. Když jich máte desítky, každá změna designu nebo textu je rozbije. Typická chyba je nahrazovat jimi integrační testy — běží pomalu, padají z nesouvisejících důvodů a tým je začne vypínat. Testujte přes stabilní selektory, ne podle textu tlačítek. A nikdy nepoužívejte produkční data.

Testovací pyramida je pomůcka, která říká, kolik testů máte mít. Nahoře jsou pomalé a drahé testy přes celou aplikaci, uprostřed integrační testy a dole rychlé unit testy. Nejde o dogma, ale o poměr, který odpovídá ceně za údržbu a rychlosti zpětné vazby. Když se poměr rozbije, vývoj se zpomalí a testy začnou překážet.

Integrační vrstva rozhoduje o důvěře Integrační testy propojují dvě až tři reálné části: aplikaci s databází, frontu se zpracovatelem, HTTP klienta s testovacím serverem. Jsou pomalejší, ale odhalí chyby v mapování, transakcích, serializaci a konfiguraci. Držte jich méně než unit testů, ale více než end-to-end. Používejte reálnou databázi v kontejneru nebo v paměti, ne ručně psané náhrady. Zásadní je izolace: každý test si připraví vlastní data a po sobě je uklidí. Sdílený stav mezi testy vede k náhodným pádům, které se těžko hledají.

Poměr není svatý. U knihovny bez uživatelského rozhraní může být pyramida skoro jen základna. U aplikace s velkým množstvím integrací se prostřední vrstva rozšíří. Sledujte dobu běhu sady a četnost pádů. Pokud unit testy trvají déle než pár sekund, něco dělají špatně. Pokud integrační testy potřebují ruční zásah, nejsou izolované. Pokud end-to-end testy padají náhodně, jsou příliš křehké. Pyramida je nástroj pro rozhodování, ne soutěž o počty.