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

Typické chyby se opakují. Testovací data se zapisují natvrdo do kódu, takže testy padají při změně prostředí. Testy závisí na sobě navzájem a jejich pořadí rozhoduje o výsledku. Čekání se řeší pevnými prodlevami místo čekání na konkrétní stav, což vede k náhodným selháním. Automatizované testy se spouštějí jen na emulátoru a nikdy na skutečném zařízení. A často chybí testy pro obnovení stavu po přerušení – třeba když uživatel přijme hovor uprostřed nahrávání.

Migrace z MySQL do PostgreSQL není jen výměna ovladače. Oba systémy mají odlišnou filozofii ukládání dat, typovou kontrolu a chování transakcí. Pokud se na to připravíte předem, vyhnete se nejčastějším chybám, které jinak vedou k tichému poškození dat nebo k výpadku aplikace po přechodu.

TypeScript tedy není otázka módy, ale velikosti a životnosti kódu. Malý nástroj zvládnete bez něj. Větší aplikace s více vývojáři a delší životností ocení, že chyby vidíte dřív a rozhraní jsou popsaná. Rozhodující není, zda typy používáte, ale zda je používáte poctivě. Jakmile začnete obcházet kontrolu přes „any" a tvrzení typů, přestává mít nástroj smysl a zůstane jen pomalejší zápis.

Během diskuze držte tři kategorie: co bylo dobré, co bylo špatné a co je nejisté. Třetí kategorie je často nejužitečnější, protože se v ní skrývají věci, o kterých se mlčí. Každý bod se musí převést na rozhodnutí: buď se změní, nebo se výslovně řekne, proč se měnit nebude. Neslibujte, že se něco udělá, když na to není kapacita. Prázdný slib je horší než žádný, protože příští retrospektiva začne nedůvěrou.

Volba open source licence není formalita, kterou lze odbýt na konci projektu. Licence určuje, co s vaším kódem smí dělat ostatní, jaké máte povinnosti při jeho šíření a jaká rizika nesete, když dílo kombinujete s cizím kódem. Než začnete cokoli zveřejňovat, ujasněte si, zda chcete, aby váš kód mohl kdokoli použít i v uzavřeném produktu, nebo zda trváte na tom, že každý, kdo ho dále šíří, musí zveřejnit i své úpravy.

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.

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.

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á.

Testovací pyramida není dogma, ale nástroj, jak rozhodnout, kde má který test vzniknout. Vychází z jednoduché myšlenky: čím rychlejší a levnější test, tím častěji ho spouštíme. Na dně stojí jednotkové testy, uprostřed integrační a nahoře end-to-end. Pokud poměr obrátíte, sada se zpomalí, začne padat z nesouvisejících důvodů a lidé jí přestanou věřit.

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é.

Po migraci spusťte srovnávací testy. Porovnejte počty řádků, kontrolní součty a výsledky klíčových dotazů. Nasaďte aplikaci nejprve na staging, kde simulujete zátěž. Teprve potom přepněte produkci. Mějte připravený rollback plán — starou databázi nechte běžet alespoň několik dní, dokud si nejste jisti, že nové řešení drží.

Častou chybou je podcenění rozdílů v řetězcích. MySQL ve výchozím nastavení nerozlišuje velikost písmen u porovnávání, PostgreSQL ano. To ovlivní vyhledávání, unikátní indexy i join podmínky. Pokud potřebujete chování bez rozlišení, použijte citext nebo funkční index s lower(). Stejně tak si ověřte práci s NULL — v MySQL je NULL ve sloupci s unique indexem povolen vícekrát, v PostgreSQL také, ale chování u složených indexů se liší.