Quelltext der Seite Když aplikaci pokrýváte testy, je čas ji vypustit ven

Pokrytí není totéž co kvalita Stoprocentní pokrytí řádků často znamená jen to, že se každý řádek alespoň jednou spustil. Netvrdí nic o tom, zda testy ověřují správné chování. Testy, které jen procházejí kódem bez kontroly výstupů, jsou dražší než žádné testy — vytvářejí falešný pocit bezpečí. Sledujte raději pokrytí větví a podmínek, ne jen řádků. A hlavně: každý test musí mít jasné očekávání, které při chybě selže. Pokud test neumí selhat, není to test.<br><br>Akce navrhujte jako malé, konkrétní události, ne jako univerzální příkazy. Místo jedné akce UPDATE s obřím payloadem použijte itemAdded, itemRemoved a itemUpdated. Reducer pak zůstane čitelný a testovatelný. U složitějšího stavu se osvědčil vzor slice: jeden soubor obsahuje počáteční stav, akce i reducer pro jednu doménu. Nesnažte se ale vytvořit jeden slice pro celou aplikaci, jinak se vrátíte k monolitickému reduceru, kterému nikdo nerozumí.<br><br>Poslední pravidlo se týká komunikace. Větve, které na sebe navazují, držte krátké a slučujte v pořadí, v jakém vznikaly. Pokud dvě větve mění stejné místo, domluvte se předem, kdo sloučí první, a teprve pak upravte tu druhou. Větvení není jen technická operace, ale dohoda mezi lidmi. Když pravidla platí pro všechny stejně, přestane být slučování stres a stane se rutinou.<br><br>Po nasazení testy nekončí. Přidávejte je k chybám, které se skutečně staly. Každý incident je zadání pro nový test. Sledujte, které testy padají často a zbytečně — ty je lepší upravit nebo smazat. Testovací sada má být živá, ne archivní. Až začnou být testy pro váš tým přítěží, je čas je protřídit, ne přestat testovat.<br><br>Kde se to láme: kultura a zodpovědnost Druhá a nejčastější chyba je rozdělení na „my" a „oni". Vývojový tým hodí kód přes zeď a provozní tým ho má rozchodit. Dokud tato hranice existuje, žádná automatizace nepomůže. DevOps znamená, že za běh služby odpovídá i ten, kdo ji napsal. To neznamená, že každý musí umět vše, ale že se nikdo neukrývá za větu „to není moje". Zaveďte společné schůzky, kde se mluví o incidentech bez hledání viníka. Pište společně dokumentaci k nasazení. Malé kroky, ale musí být vidět, že je děláte spolu.<br><br>Kdy je tedy čas pustit aplikaci ven? Ve chvíli, kdy máte pokryté všechny kritické cesty, když testy procházejí na čistém prostředí a když víte, co se stane při chybě. Není potřeba čekat na dokonalé pokrytí. Nasadit se dá i s menším počtem testů, pokud máte monitoring, rollback a rychlý způsob, jak opravit chybu. Naopak bez testů a bez možnosti rychle reagovat je vypuštění ven hazard.<br><br>Praktický přístup je začít od kritických cest. Přihlášení, platba, uložení dat, změna oprávnění. Tyto části potřebují testy na úrovni integrace, protože chyby v nich mají přímý dopad na uživatele. Pomocné funkce a utilitky stačí pokrýt jednotkovými testy. Neplýtvejte časem na testování kódu, který se brzy změní nebo zmizí. Testy u takového kódu zestárnou dřív než kód sám.<br><br>Čistý kód v JavaScriptu nepoznáte podle toho, že funguje. Fungovat může i změť funkcí, které se navzájem volají přes globální proměnné. Čistý kód poznáte podle toho, že ho za půl roku pochopíte i vy sám, a že ho bez obav upraví někdo jiný. Rozdíl mezi čitelným a nečitelným kódem přitom není v délce ani v použitém frameworku. Je v rozhodnutích, která děláte při psaní každé funkce.<br><br>Poslední rada: nezačínejte celou transformací najednou. Vyberte jednu službu, jeden tým a jeden problém, který vás bolí. Změřte, jak je na tom nyní. Zaveďte jednu změnu – třeba společný chat pro incidenty nebo automatické testy. Po týdnu zkontrolujte, zda to pomohlo. Teprve pak přidávejte další. DevOps je běh na dlouhou trať, ne sprint. Kdo to zkusí přeskočit, většinou skončí s hromadou nástrojů a stejně pomalým nasazením.<br><br>Větve pojmenovávejte podle účelu, ne podle jména autora. Formát jako typ/issue-strucny-popis (např. feat/platby-refund nebo fix/prihlaseni-timeout) drží pořádek i ve chvíli, kdy je v repozitáři otevřených větví dvacet. Před vytvořením větve vždy aktualizujte hlavní linii a teprve z ní odbočte. Větev vytvořená ze zastaralého stavu přináší konflikty, které nemají nic společného s vaší prací, a jejich řešení zabere čas, který jste mohli věnovat funkci.<br><br>Testy nejsou cíl, ale nástroj. Přestanou být užitečné ve chvíli, kdy začnou brzdit vývoj rychleji, než odhalují chyby. Aplikace bez testů se ale nedá bezpečně nasadit. Proto je potřeba hledat hranici, kdy je pokrytí dostatečné a kdy nastal čas pustit aplikaci mezi uživatele. Tato hranice není univerzální, závisí na typu projektu, kritičnosti chyb a rychlosti, s jakou se mění požadavky.