Větev, nebo fork: co rozhoduje o hladkém vývoji
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.
Většina týmů, které si stěžují na chaotické mergování, nemá problém v nástroji, ale v tom, že si nikdy nedohodla, kdo co vlastně dělá. Git je distribuovaný systém a bez pravidel se každý vývojář chová jako samostatný ostrov. První krok tedy není technický, ale organizační: sepište na jednu stránku, jaké větve budete používat a k čemu slouží. Bez toho se dřív nebo později stane, že dva lidé upraví stejný soubor a výsledek bude horší než předtím.
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é pro 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.
Základem je dlouho žijící hlavní větev, obvykle main nebo master, která by měla vždy obsahovat nasaditelný stav. Do ní se nikdy necommituje přímo. Každá změna vzniká na krátké větvi, jejíž název nese účel: oprava přihlášení, nový filtr v seznamu, aktualizace závislostí. Krátká větev znamená jednotky dní, ne týdny. Čím déle větev žije, tím větší je vzdálenost od main a tím bolestivější je návrat. Větve pojmenovávejte malými písmeny s pomlčkami, ať se v nich dá hledat a ať je na první pohled jasné, co řeší.
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.
Typická chyba je dlouhé držení větve a čekání na schválení. Další je force push do sdílené větve, který smaže kolegům jejich commity. Vyhněte se také commitům se zprávami typu „oprava" nebo „úpravy". Zaveďte si pravidlo, že hlavní větev je chráněná a přímý push do ní není možný. Tým, který dodržuje krátké větve, jasné zprávy a povinnou kontrolu, stráví méně času hašením požárů a více psaním kódu, který funguje.
Základní pravidlo zní: pokrytí měřte tam, kde může selhání způsobit reálnou škodu. Platební logika, výpočty, validace vstupů nebo stavové automaty si vysoké pokrytí zaslouží. Naopak jednoduché gettery, konfigurační konstanty nebo automaticky generovaný kód nemá smysl honit na sto procent. Pokud tým tráví čas psaním testů jen proto, aby v reportu svítilo vyšší číslo, přesunul se od kvality k vanity metrice.
Kdy se z pokrytí stává past Prvním varovným signálem je situace, kdy testy volají funkci, ale nekontrolují žádný výstup. Projdou všemi řádky, zvýší pokrytí, ale chybu v logice neodhalí. Druhým je snaha pokrýt i triviální a stabilní části, zatímco kritické větve zůstávají netknuté. Třetím je tlak na procenta shora: jakmile se z pokrytí stane cíl, začnou vznikat testy bez hodnoty. Čtvrtým je ignorování toho, jaký typ pokrytí sledujete – řádkové, větvové nebo podmínkové. Každý vypovídá o něčem jiném a zaměňovat je vede k falešnému pocitu bezpečí.
Měření pokrytí kódu testy vypadá jako jednoznačné číslo, které lze snadno vykázat. Právě proto se často zneužívá. Pokrytí samo o sobě neříká, zda testy něco skutečně ověřují, nebo jen procházejí řádky kódu, aniž by kontrolovaly výsledek. Užitečné je pouze tehdy, když ho čtete společně s kvalitou testů a rizikem konkrétního kódu.
Pokrytí přestává být užitečné ve chvíli, kdy se stane cílem místo nástrojem. Jakmile tým píše testy kvůli reportu, přestává řešit, co má být ověřeno. Stejně tak ztrácí smysl, když se jím poměřují lidé nebo když se porovnávají nesrovnatelné projekty. Číslo bez kontextu neřekne nic o tom, zda je software spolehlivější. Říká jen, kolik řádků bylo spuštěno.
Pozor na práci s testy, které jen zvyšují pokrytí. Často vznikají tak, že se testuje privátní metoda přes veřejné rozhraní, ale bez kontroly stavu. Takový test projde, i když logika vrátí špatný výsledek. Místo toho se zaměř na chování: co má funkce vrátit, jaké chyby má vyhodit, jak se změní stav. Pokud test neumí selhat při změně logiky, nemá cenu. Stejně tak nepomůže testovat gettery a settery jen proto, aby vyskočilo procento.