michaldabrowski73

Když vaše codebase roste, jednotkové testy zůstávají prvním obranným valem, ale jejich slepé hromadění může vést k falešnému pocitu jistoty. Začněte tím, že si rozdělíte testy podle rychlosti a izolace: jednotkový test by neměl opustit hranice jedné třídy nebo funkce a měl by běžet v řádu milisekund. Integrační testy naopak pokrývají agilní metodiky , databázi či externí služby, a proto jsou řádově pomalejší. Praktickým vodítkem je poměr 70:20:10 ve prospěch jednotkových testů, ale toto číslo berte jako výchozí bod, ne dogma. Důležité je, abyste si pro každou novou funkci položili otázku: co se může rozbít? Podnikovou logiku, validace a čisté funkce testujte jednotkově, zatímco toky přes více vrstev (například od kontroleru k repozitáři) pokryjte integračně. Vyhnete se tak situaci, kdy máte tisíce mocků, které pouze ověřují, že se testy samy chovají správně. Jakmile začnete testy třídit, všimnete si, že klíčová je smluvní stabilita mezi vrstvami. Právě zde integrační testy odhalují skutečné propojení: změna databázového schématu, formátu API odpovědi nebo chování knihovny třetí strany je nezachytí žádný mock. Proto si definujte malý počet kritických integračních testů pro hlavní uživatelské scénáře – třeba deset až dvacet – a udržujte je vždy zelené. Naopak u jednotkových testů se zaměřte na rychlou zpětnou vazbu při vývoji: spouštějte je při každém uložení a nechte je běžet kontinuálně. Jestliže se integrační testy začnou prodlužovat nad pár minut, je to signál, že je čas je rozdělit podle domén nebo běhat jen v rámci konkrétních větví. Vyvážení těchto dvou skupin nespočívá v striktní kvantitě, ale v tom, že jednotkové testy chrání každou funkci a integrační testy chrání to, co funkce spojuje – tedy celé uživatelské příběhy. Zásadní pravidlo pro udržení rovnováhy při růstu zní: pište nové testy až tehdy, když máte jasno o chování, a při každém refaktoru sledujte, který typ testu vás nejvíce zdržuje. Pokud změny v jedné třídě nutí přepisovat desítky mocků, máte příliš těsné jednotkové testy zaměřené na implementaci, ne na chování. Přesuňte těžiště na integrační testy, které se nemění, dokud se nezmění kontrakt. Naopak, pokud se vám integrační testy stávají úzkým hrdlem, protože každá drobnost spouští celou databázi, vraťte se k čistším jednotkovým testům s falešnými objekty. Tím se dostáváte k jádru testovací pyramidy – chcete širokou, rychlou základnu a úzký, pomalejší vrchol. Nebojte se testy i mazat: když vám test začne vyžadovat více údržby než produkční kód, který chrání, je to signál, že je špatně postavený. Průběžně sledujte, kolik času věnujete opravám testů versus opravám kódu – tento ukazatel vám řekne, zda je vaše testovací pyramida zdravá. A pamatujte, že dokonalý poměr neexistuje; existuje pouze rovnováha, kterou průběžně ladíte podle toho, co vám aktuálně způsobuje největší provozní bolest.