Jakmile je jednotková vrstva pevná, přejděte na integrační testy. Ty ověřují, že vaše komponenty spolupracují správně – typicky s databází, externími službami nebo frontendem. Zde platí pravidlo: testujte jen to, co jednotkově nejde pokrýt. Například mapování ORM, SQL dotazy nebo synchronizaci mezi moduly. U integračních testů si dejte pozor na stav prostředí. Vždy používejte izolovanou testovací databázi a po každém běhu ji vracejte do původního stavu. Jinak se vám testy navzájem ovlivňují a vy strávíte hodiny hledáním chyby, která je jen artefaktem pořadí testů.

Testovací pyramida není jen teoretický model, ale praktický nástroj, který vám pomůže udržet náklady na testování pod kontrolou. Základní myšlenka je jednoduchá: čím níže v pyramidě test stojí, tím by ho mělo být více, a naopak. Na dně jsou rychlé a levné jednotkové testy, uprostřed integrační testy a na vrcholu pomalé end-to-end testy. Když tohle rozdělení nedodržíte, skončíte s testy, které běží desítky minut, jsou křehké a při každé změně kódu vyžadují ruční opravy.

Když test napíšete, spusťte ho. Pokud projde, zkuste ho schválně rozbít změnou očekávané hodnoty. Tím si ověříte, že test skutečně funguje a není jen formální. Poté hodnotu vraťte zpět. Tento postup je dobré si zapamatovat, protože odhaluje falešně zelené testy, které testují špatnou věc. Jakmile máte první test hotový, pokračujte dalším. Postupně získáte jistotu a testování se stane přirozenou součástí vašeho vývoje.

Pro udržení čisté historie je klíčové pravidelně rebase proti hlavní větvi, ne merge. Rebase přepíše historii tak, že vaše commity navazují na aktuální stav mainu, což usnadňuje pozdější začlenění. Při rebase ale pozor na konflikty – řešte je hned, neodkládejte. Pokud konflikty vznikají opakovaně ve stejných souborech, je to signál, že byste měli komunikovat s kolegy, kdo na čem pracuje, a případně si rozdělit soubory, aby se předešlo zbytečným srážkám.

Při psaní testu si dejte pozor na použití ostrých dat z produkce. Test by měl být vždy nezávislý na okolním prostředí. Pokud test používá datum a čas, nezadávejte aktuální hodnotu, ale pevně zvolenou konstantu. Stejně tak se vyhněte náhodným hodnotám, které test dělají nestabilním. Test, který občas selže, pozbývá smyslu. Pro první test zvolte natvrdo zadaná data, abyste měli jistotu, že výsledek je vždy stejný.

Při práci na více feature větvích také vždy synchronizujte svůj lokální repozitář s originem, ale ne jen jednou na začátku. Průběžně si stahujte změny z mainu a rebasujte svou větev. Můžete si nastavit automatický fetch, ale raději si na to udělejte zvyk. Klíčem je, aby vaše větev nebyla nikdy příliš vzdálená od mainu. Pokud na ní pracujete déle než týden, zvažte, zda nemá smysl rozdělit ji na menší části, které lze dílčím způsobem začlenit.

Časté chyby a jak se jim vyhnout Jednou z nejčastějších chyb je testovat více věcí najednou. Pokud test selže, nevíte přesně, která část kódu je rozbitá. Rozdělte testy na malé, jednotlivé případy. Dalším problémem je používání reálných závislostí, jako jsou databáze nebo souborový systém. Takové testy jsou pomalé a nedeterministické. Řešením je použít falešné objekty (mocking), ale pozor – nezacházejte do extrému. Příliš mnoho mocků může testy učinit nepřehlednými a křehkými.

Jak bezpečně začlenit hotovou větev a nerozbít main Než začnete větev začleňovat, ujistěte se, že prošla testy a kontrolou kódu. Mnoho týmů používá takzvaný „pull request” s povinnou revizí od jiného vývojáře. Tím se výrazně snižuje riziko, že se do mainu dostane chyba. Před merge je také vhodné provést rebase a po něm spustit testy znovu, protože po přepsání historie se může chování změnit. Pokud používáte merge commit, držte ho vždy jako poslední a neprovádějte žádné další úpravy do větve po začlenění.

Dalším častým problémem je nevhodné pojmenování větví. Místo obecných názvů jako „oprava” nebo „feature” používejte strukturu, která napoví, o co jde – třeba „feat/prihlasovani”, „fix/chybny-vypocet-dph”. To pomůže nejen vám, ale i ostatním členům týmu rychle identifikovat účel větve. Dobré je také zaznamenat do názvu číslo úkolu z vašeho systému, pokud ho používáte, ale není to nutné.

Při testování IDE si všímejte, jak rychle se otevře a jak reaguje na psaní. Některá prostředí jsou náročná na paměť, což oceníte na výkonném počítači, ale na starším notebooku vás to bude brzdit. Typická chyba: stáhnete si nejpopulárnější nástroj, ale po pár týdnech zjistíte, že vám nevyhovuje jeho vzhled nebo náročnost konfigurace. Místo toho vyzkoušejte tři nebo čtyři různé možnosti a věnujte každé alespoň jeden den. Pracujte na reálném projektu, ne jen na ukázkové úloze, protože teprve tak odhalíte, co vám nástroj usnadňuje a co naopak komplikuje.