Když se testy množí, rozhoduje jejich uspořádání

Vyhněte se dvěma častým omylům. Prvním je snaha mít „test na všechno" a měřit kvalitu procentem pokrytí. Pokrytí říká, co je spuštěno, ne co je ověřeno. Druhým je ignorování rychlosti. Test, který běží deset minut, vývojáři přestanou pouštět. Rozdělte sadu na rychlou, která běží při každém commitu, a pomalou, která se spouští před vydáním. Každý test musí mít jasný důvod, rady pro rekonstrukcič existuje. Když ho neumíte pojmenovat, pravděpodobně jen zdržuje.

Zaveďte oddělené spouštění: jednotkové testy při každém uložení souboru, integrační před commitem nebo v CI. Nikdy nemíchejte obě vrstvy v jednom cíli, jinak přijdete o rychlou zpětnou vazbu. Sdílená fixtures a pomocné buildery držte v samostatném modulu, ať se nekopírují mezi vrstvami. Pozor na globální stav – statické proměnné, mezipaměti a časovače způsobují, že integrační testy procházejí jen v určitém pořadí.

Konflikty řešte hned, ne odkladem. Pokud při rebase narazíte na konflikt, přečtěte si obě strany a rozhodněte, která verze je správná. Nikdy nenechávejte v souboru značky konfliktu ani „obě varianty" rady pro rekonstrukci jistotu — tím vzniká kód, kterému nikdo nerozumí. Po vyřešení spusťte testy znovu, protože sloučení mohlo změnit chování i tam, kde konflikt nebyl.

Praktický postup je jednoduchý. Nejdřív napište unit testy pro novou logiku. Potom přidejte integrační test pro každé nové propojení, které může selhat. A e2e test doplňte jen tam, kde by chyba znamenala, že uživatel nemůže dokončit klíčovou činnost. Poměr se bude lišit podle typu projektu, ale základna má vždy převažovat. U knihovny může být poměr výrazně ve prospěch unit testů, u aplikace s mnoha rozhraními se integrační vrstva rozroste.

Začni tím, že si v projektu spustíš git init. Tím vznikne skrytý adresář .git, kam se ukládá veškerá historie. Potom přidej soubory do indexu pomocí git add a ulož je příkazem git commit -m "popis změny". Pozor na typickou chybu: lidé napíšou git commit bez předchozího git add a diví se, že se nic neuložilo. Index funguje jako přípravná zóna – co tam nedáš, to se necommitne.

Větve, konflikty a jak je řešit bez paniky Větve ti umožní zkoušet změny, aniž bys rozbil hlavní verzi. Vytvoříš ji příkazem git branch nazev a přepneš se pomocí git checkout nazev. Když na větvi dokončíš práci, sloučíš ji do hlavní pomocí . Právě při sloučení vznikají konflikty, pokud se stejná část souboru změnila na dvou místech. Git ti je označí v souboru a ty musíš ručně rozhodnout, která verze zůstane. Nenechávej konflikt nevyřešený a necommituj ho – vznikne zmatek, který se těžko rozplétá.

Časté chyby mají společné jméno: „any" a tvrzení typu. Když napíšete „něco as SomeType", jen tím překladateli řeknete, ať věří, že data mají tvar, který nemají. Kontrola projde a chyba se objeví až v provozu. Stejně zrádné je ignorovat návratové hodnoty funkcí, které mohou vrátit null. Řešení není složité: vždy pracujte s možností, že hodnota chybí. Pomůže volitelný řetězec „?.", výchozí hodnota přes „??" a úzké typy místo širokých. Místo „string" použijte konkrétní unijní typ, pokud znáte povolené hodnoty.

Testovací pyramida není dogma, ale poměr, který udržuje zpětnou vazbu rychlou a levnou. Základ tvoří unit testy: měly by pokrývat izolovanou logiku, hraniční hodnoty a chybové stavy. Držte je v řádu milisekund, bez sítě, bez souborového systému a bez databáze. Když unit test potřebuje kontejner nebo běžící server, není to unit test. Čím více jich je, tím častěji můžete spouštět celou sadu při každé změně.

Mezi nejčastější chyby patří commitování velkých nebo citlivých souborů. Do repozitáře nepatří hesla, klíče ani dočasné soubory. Vytvoř soubor .gitignore a vypiš do něj vzory, které má Git ignorovat. Další častá chyba je práce přímo v hlavní větvi bez zálohy. Pokud něco pokazíš, můžeš sice použít git reset nebo git revert, ale je snazší mít změny na samostatné větvi a jen je sloučit, až fungují.

Kde končí rozumná hranice Vrchol pyramidy tvoří end-to-end testy. Procházejí celou aplikaci z pohledu uživatele a mají největší hodnotu při ověřování kritických cest: přihlášení, dokončení interiéru objednávky, odeslání formuláře. Zásadní je držet jejich počet nízký. Každý e2e test je pomalý, křehký a jeho selhání často neukazuje na chybu v logice, ale na změnu v rozhraní nebo v datech. Pokud jich máte desítky, brzy strávíte více času jejich opravami než vývojem.

Verzování není jen formalita pro programátory. Jakmile začneš upravovat jakýkoli soubor, ať už jde o kód, text nebo konfiguraci, bez historie změn se ztrácí přehled. Git řeší přesně to: ukládá snímky stavu, takže se můžeš kdykoli vrátit k předchozí verzi. První krok je pochopit tři místa, kde se soubory nacházejí: pracovní adresář, index (staging area) a repozitář. Většina začátečníků si plete, co je kde, a proto jim změny mizí.