Edytujesz Testovací pyramida versus hromada skriptů: kde se ztrácí signál

Před podpisem smlouvy si vyžádejte informace o tom, jak často vycházejí aktualizace a jak jsou oznamovány změny v chování. Zjistěte, zda je možné provozovat podporu odděleně od databázového serveru, aby její pád neohrozil samotná data. A hlavně – ověřte, jak vypadá obnova po výpadku. Ne teoreticky, ale konkrétně: kolik kroků je potřeba udělat a jak dlouho to trvá. Bez toho zůstává volba podpory jen hrou na jistotu, která v ostrém provozu neobstojí.<br><br>Největší chybou je poměr obrátit: mnoho e2e testů a málo jednotkových. Další je sdílený stav mezi testy. Test, který projde sám, ale selže v sadě, obvykle závisí na datech z předchozího běhu. Řešením je izolace a deterministická data. Pyramidu nevnímejte jako početní poměr, ale jako rozhodnutí, kde zaplatíte za rychlost a kde za věrnost.<br><br>Praktický postup je následující. Nejprve si napište seznam operací, které aplikace reálně potřebuje, a u každé uveďte, jak často a na jak velkých datech běží. Potom pro každou operaci zjistěte, zda ji databáze zvládá sama, nebo zda ji nahrazujete ručně. U ručních náhrad spočítejte režii: kolik dat se přenáší, kolik paměti to spotřebuje a co se stane při desetinásobném růstu. Pokud se režie vymkne kontrole, je čas buď změnit databázi, nebo upravit datový model tak, aby operace byly nativně podporované.<br><br>Praktický postup: nejdřív napište jednotkový test pro novou logiku, pak integrační pro hranici systému a e2e jen pro scénář, který by jinak nikdo neověřil. Sledujte dobu běhu. Pokud sada jednotkových testů trvá déle než několik sekund, něco děláte špatně. Pokud integrační testy vyžadují ruční spuštění databáze, ztratí se v CI a přestanou se spouštět.<br><br>Důležitá je i otázka, kdo bude podporu ovládat. Pokud s databázemi teprve začínáte, potřebujete řešení s rozumným výchozím nastavením a srozumitelnými výstupy. Naopak zkušený tým ocení možnost zasáhnout do konfigurace a přizpůsobit chování. Nenechte se zlákat tvrzením, že vše zvládne jediné tlačítko. Většina incidentů vzniká v okamžiku, kdy se něco pokazí a není jasné, jak to vrátit zpět.<br><br>Proveďte audit stávající sady a u každého testu odpovězte na jednu otázku: závisí výsledek na stavu mimo testovanou funkci? Pokud ne, patří do jednotkové vrstvy. Pokud ano, do integrační. Testy, které nedokážou odpovědět ani na jednu variantu, obvykle jen kopírují implementaci a nemají hodnotu – ty smažte. Počet integračních testů držte výrazně nižší než jednotkových, obvykle v poměru jedna ku pěti až jedné ku deseti.<br><br>Výběr podpory pro databáze nezačíná u ceny ani u seznamu funkcí. Začíná u toho, co vaše aplikace skutečně dělá. Jinou podporu potřebuje skladová evidence s tisíci transakcí za minutu a jinou reportovací nástroj, který se dotazuje jednou denně. Než se pustíte do srovnávání, sepište si tři věci: jaký typ dotazů převažuje, jaký je poměr čtení a zápisu a jak dlouho si můžete dovolit výpadek. Teprve pak má smysl řešit konkrétní řešení.<br><br>Na vrcholu stojí end-to-end testy. Ověřují scénář z pohledu uživatele, ale jsou nejdražší na údržbu. Nemá smysl jimi pokrývat každou kombinaci vstupů. Vyberte kritické cesty: přihlášení, platba, uložení objednávky. Pokud e2e test padá kvůli změně textu v tlačítku, je příliš křehký a patří do nižší vrstvy. Stabilita je důležitější než pokrytí.<br><br>Zaměřte se na režim provozu, ne na reklamní slogany Podpora pro databáze se dělí podle toho, jak zasahuje do běhu systému. Některá řešení jen sledují stav a upozorní na problém, jiná aktivně přesouvají zátěž nebo automaticky opravují chyby. U sledovacích nástrojů si ověřte, jak často sbírají data a zda zvládnou i krátké špičky. U aktivních zásahů naopak hlídejte, zda nezpůsobí neplánovaný restart nebo zámek, který zablokuje ostatní dotazy. Praxe ukazuje, že příliš agresivní automatika dokáže nadělat víc škody než užitku, pokud není pečlivě nastavená.<br><br>Poslední věc je práce s daty. Nepoužívej globální proměnné, pokud to není nutné. Předávej hodnoty parametrem nebo je drž v uzavřeném rozsahu. U polí a objektů dávej pozor na sdílené reference — když jedno místo v kódu změní objekt, změní se i jinde. Čistý kód se pozná tak, že změna na jednom místě nevyvolá překvapení na druhém. To je celý cíl, nic víc za tím nehledej.<br><br>Rozdělte testování na několik úrovní. Unit testy ověřují jednotlivé funkce a běží rychle při každé změně. Integrační testy kontrolují spolupráci mezi moduly, například mezi sítí a lokální databází. UI testy simulují skutečné chování uživatele a odhalí problémy s rozvržením či navigací. Ruční průzkumné testování pak doplní to, co automatizace nepokryje – neobvyklé kombinace kroků, přerušení hovorem, otočení displeje, slabý signál.