Když změníte pyramidu testů, přestanou vám padat releasy

Typické chyby při výběru jsou tři. První je výběr podle toho, co je zrovna v módě, bez vztahu k vlastnímu cíli. Druhá je snaha naučit se dva jazyky současně, což vede k povrchním znalostem od obou. Třetí je odkládání praxe – sledování videí a čtení knih bez psaní vlastního kódu. Platí, že za první měsíc napíšete více kódu než za tři měsíce pasivního studia. Stanovte si proto malý projekt, který vás baví, ať už jde o převodník jednotek, evidenci knih nebo jednoduchou hru.

Nakonec si hlídejte, aby se pyramida nezvrhla v přesýpací hodiny. Jakmile začne převažovat jedna vrstva, ať už unit nebo E2E, znamená to, že ostatní vrstvy neplní svou roli. Pravidelně, třeba jednou za čtvrt roku, se podívejte na poměr testů a na to, jak dlouho běží. Pokud se poměr vychýlí, přesuňte testy tam, kam patří. V dynamickém projektu není pyramida pevná stavba, ale něco, co se neustále vyvažuje.

Přesuňte těžiště tam, kde se změny dějí Základní pravidlo zní: čím blíž k byznys logice, tím víc testů. Pokud se často mění pravidla, výpočty nebo workflow, vyplatí se posílit vrstvu testů na úrovni služeb a modulů, ne jednotlivých funkcí. Unit testy pište jen tam, kde jde o složitou logiku bez závislostí – ne plošně na každý getter. Místo stovek drobných testů postavte sadu, která ověřuje celé scénáře na úrovni domény. Ty se při změně požadavku upravují na jednom místě, ne na dvaceti.

Nakonec mějte na paměti, že falešné závislosti musí věrně kopírovat kontrakt. Pokud se reálné API změní, fake implementace může zůstat zastaralá a testy projdou, i když aplikace v produkci selže. Proto udržujte fake třídy co nejblíže skutečnému rozhraní a při každé změně API je aktualizujte. Pomůže i kontraktní test, který ověří, že se fake chová stejně jako reálná služba – alespoň na základní úrovni.

Uložení klíče patří do transakce spolu s vlastní operací. Pokud nejdřív zapíšete výsledek a pak klíč, může selhat zápis klíče a při opakování vznikne duplicita. Vhodné je použít databázi s unikátním indexem na kombinaci klíče a uživatele. Při souběhu dvou požadavků se stejným klíčem jeden zápis uspěje a druhý dostane konflikt. Tento konflikt se nemá vracet jako chyba 500, ale jako 409 nebo 200 s původním výsledkem. Doba platnosti klíče má být omezená, obvykle hodiny až dny. Příliš krátká expirace dovolí duplicitu později, příliš dlouhá zbytečně plýtvá místem.

Na co si dát pozor při návrhu závislostí První pastí je příliš těsné propojení s konkrétní knihovnou. Pokud všude voláte přímo HTTP klienta, nemáte kam vložit falešnou implementaci. Vždy definujte rozhraní a injektujte závislost přes konstruktor nebo parametr. Druhou pastí je ignorování chybových stavů. Externí služba může vrátit timeout, chybu 500 nebo neplatný formát odpovědi. Testy musí tyto situace pokrýt, jinak zůstanou skryté. Třetí častou chybou je, že fake implementace vrací vždy stejnou odpověď a testy pak neodhalí změny v logice.

Testování aplikace, která komunikuje s externími službami, často skončí tak, že vývojář buď spoléhá na živé API, nebo testy úplně vynechá. Ani jedno není správné. Živé API je pomalé, nedeterministické a při výpadku sítě shodí celou sadu testů. Vynechání testů zase znamená, že se chyby v integraci objeví až v produkci. Řešením je nahradit externí služby vlastními závislostmi, které simulují chování rozhraní.

Základ responzivity není v médiích, ale v tom, že layout sám povolí zmenšení. Grid postavte pomocí grid-template-columns: repeat(auto-fit, minmax(260px, 1fr)). Tento zápis vytvoří tolik sloupců, kolik se jich do šířky vejde, a každý bude mít minimálně 260 pixelů. Šířku nerozbijete pevnými hodnotami v pixelech, ale relativními jednotkami fr, % nebo min(). U Flexboxu používejte flex-wrap: wrap a u potomků flex: 1 1 260px. Tím dosáhnete stejného efektu bez jediného media query.

Pro datové závislosti, jako je databáze, použijte in-memory úložiště nebo dočasný soubor. Není nutné spouštět celý databázový server. Například v Javě stačí H2 v paměti, v Pythonu SQLite. Důležité je, aby se data mezi testy izolovala – každý test by měl začínat s čistým stavem. Dosáhnete toho buď vytvořením nové instance před každým testem, nebo transakcí, která se na konci rollbackne. Pokud použijete sdílenou databázi, testy si navzájem přepisují data a výsledky jsou náhodné.

Mezi nejčastější chyby patří nasazování v pátek odpoledne, rollback bez zálohy dat, spoléhání na to, že někdo „to" zvládne ručně, a chybějící monitoring po návratu. Po rollbacku je nutné ověřit nejen dostupnost, ale i správnost dat a front. Až poté se řeší příčina. Následná analýza má odpovědět na tři otázky: co se změnilo, proč to neodhalily testy a jak se příště zkrátí čas do detekce. Bez ní se stejná chyba vrátí při dalším nasazení.