Když se testy množí bez plánu, pyramidová struktura to spraví

Druhá chyba je přílišné mockování. Když je každá závislost nahrazená atrapou, test neověří nic skutečného. Držte se pravidla: mockujte jen to, co je pomalé, nedeterministické nebo mimo vaši kontrolu. Databázi v integračních testech raději spouštějte skutečnou, klidně v kontejneru, a po každém testu ji resetujte. Testy tak zůstanou věrohodné a přitom opakovatelné.

Lidé jsou třetí a největší překážka. Pokud provozní tým cítí, že mu vývojáři předávají nehotovou práci, a vývojáři zase, že je provoz brzdí, žádná automatizace to nespraví. Pomáhá společné vlastnictví služby, společné pohotovosti a to, že se incidenty rozebírají bez hledání viníka. Chyby se mají zapisovat a opravovat v systému, ne v lidech. Teprve když obě strany vidí stejná data a mají stejný cíl, začne DevOps dávat smysl.

Verzovací systém není nástroj, který si nastavíte jednou a pak na něj zapomenete. U webových projektů se do něj sahá několikrát denně, takže záleží hlavně na návycích. První krok nejsou příkazy, ale rozhodnutí, co vlastně chcete sledovat. Do repozitáře patří zdrojové soubory, konfigurace šablon, skripty sestavení a dokumentace. Naopak závislosti stažené správcem balíčků, výstupní složky sestavení, lokální konfigurace s hesly a nahrané soubory od uživatelů tam nepatří.

Začněte tím, že si sepíšete, co vlastně testujete. U každé části kódu si položte otázku, zda jde o čistou logiku, spolupráci komponent, nebo chování celého systému. Jednotkový test má pokrýt rozhodování, hraniční hodnoty a chybové stavy. Integrační test ověří, že spolu moduly mluví správně přes rozhraní, databázi nebo frontu. End-to-end test patří jen na kritické cesty, které musí fungovat vždy, například dokončení objednávky.

Na co si dát pozor u datových typů a dotazů Zásadní rozdíl je v datových typech. MySQL je tolerantnější: například INT bez znaménka, TINYINT jako boolean nebo ENUM se v PostgreSQL chovají jinak. Datum 0000-00-00, které MySQL běžně přijme, PostgreSQL odmítne. Podobně řetězce s neplatnými znaky nebo prázdné hodnoty v číselných sloupcích. Před migrací je proto nutné data vyčistit a ověřit, že každý sloupec odpovídá cílovému typu. Nejedná se o formalitu – neplatná hodnota zastaví import celé tabulky.

Kde pyramida v praxi selhává Nejčastější chyba je nahrazení pyramidy zmrzlinovou kornoutkem: mnoho pomalých end-to-end testů a skoro žádné jednotkové. Vzniká to tak, že se testy píší až po nasazení a přes uživatelské rozhraní. Řešení není psát víc testů, ale přesunout odpovědnost níž. Když test selže, má být jasné, která vrstva to způsobila. Pokud k opravě potřebujete spustit celou aplikaci, test je příliš vysoko.

Posledním krokem je zkušební provoz s reálnou zátěží. Sledujte dobu odezvy dotazů, plány provádění a chování transakcí. Teprve když aplikace i data projdou kontrolou, odpojte původní databázi. Většina problémů se totiž neprojeví při importu, ale až při prvním ostrém dotazu.

Retrospektiva bez struktury se často zvrhne v nebo v ticho, které nikam nevede. Stačí málo: dát zpětné vazbě jasný rámec, který donutí lidi mluvit konkrétně a k věci. Nejde o to zavést složitý proces, ale o to, aby každý věděl, co a jak má říct.

Praktický postup je zavést pyramidu do CI postupně. Nejprve zrychlete jednotkové testy tak, aby běžely do několika sekund. Pak přidejte integrační sadu, která se spouští při každém commitu. End-to-end testy nechte na noční běh nebo před vydáním. Sledujte dobu běhu a flakiness. Každý test, který občas padá bez změny kódu, buď opravte, nebo smažte. Nespolehlivá sada je horší než žádná.

Prvním krokem je zmapovat, co databáze skutečně obsahuje. V MySQL často zůstávají tabulky bez primárního klíče, sloupce s implicitními hodnotami, uložené procedury a triggery v proprietární syntaxi. Všechny tyto objekty je nutné projít ručně. Automatické konvertory sice převedou většinu DDL, ale výrazy specifické rady pro rekonstrukci MySQL zůstanou nepřeložené nebo se přeloží špatně. Výsledkem bývá schéma, které se sice vytvoří, ale neodpovídá původní logice.

U čistého Node.js narazíte na stejné problémy, jen dřív. Musíte ručně rozlišit metodu a cestu, načíst tělo po částech, ošetřit maximální velikost a sestavit odpověď včetně hlaviček. Výhodou je menší závislost a jasná představa o tom, co se v aplikaci děje. Nevýhodou je, že každý nový endpoint znamená další kód, který se snadno zvrhne v nepořádek. Express tuto režii odstraňuje a drží strukturu čitelnou i při desítkách tras.

Nakonec si hlídejte poměr, ale ne slepě. U malé služby může stačit pár jednotkových a jeden integrační test. U složitého systému s mnoha rozhraními bude integrační vrstva silnější. Pyramida je vodítko pro rozhodování, ne soutěž o počty. Když každý test ví, co ověřuje, a běží na správné vrstvě, sada zůstane rychlá, srozumitelná a užitečná i po letech.