První unit test píšete snadno, když víte, co testovat

Typická chyba je psát testy, které závisí na pořadí provedení. Testy musí být izolované – každý běží sám za sebe a nespoléhá se na stav z předchozího testu. Pokud potřebujete připravit data, udělejte to v metodě, která se volá před každým testem. Vyhněte se také testování implementace – testujte chování, ne to, jak je funkce napsaná. Když později změníte vnitřní kód, testy by měly zůstat beze změny.

Nakonec myslete na to, že dokumentace je živý artefakt. Stanovte odpovědnost – backendový vývojář, který endpoint vytvoří, by měl také aktualizovat popis. Pravidelně kontrolujte, že příklady v dokumentaci odpovídají reálným odpovědím. Automatizovaný skript, který porovná schéma se skutečnou odpovědí, vám ušetří ruční kontrolu. Když dokumentace přestane lhát, frontend přestane hádat a spolupráce se stane plynulou – což je přesně to, co od dobré dokumentace očekáváte.

Základem je popis všech endpointů s jejich metodami, cestami a parametry. Každý parametr by měl mít jasný typ, povinnost a příklad hodnoty. Užitečné je také uvést, jestli se předává v query, cestě nebo hlavičce. Nezapomínejte na chybové stavy – definujte, co se stane při neplatném vstupu, a to nejen obecně, ale pro každý endpoint zvlášť. Chybový payload by měl obsahovat strojově čitelný kód a lidsky srozumitelnou zprávu, ne jen HTTP status.

Zásadní je také udělat z testů součást vývojového workflow, ne něco, co se spouští příležitostně. Zařaďte rychlé jednotkové testy do pre-commit hooků, integrační testy do CI po pushnutí a end-to-end testy do nočního běhu. Udržujte časy běhu pod kontrolou: když vám jednotkové testy trvají deset sekund, je to v pořádku, ale když pět minut, začněte je paralelizovat. Když se test stane nestabilním, raději ho přeskočte a opravte, než abyste ho mazali — ale mějte seznam takových přeskočených testů, aby se na ně nezapomnělo.

Typickou chybou je snaha o 100% pokrytí kódu. Vysoké procento pokrytí neznamená, že testy ověřují správné chování. Zaměřte se raději na kritické části systému: platební tok, oprávnění uživatelů, zpracování chyb. Tyto oblasti by měly mít pokrytí vysoké, zatímco pomocné funkce nebo jednoduché gettery lze pokrýt s nižším rozsahem. Nezapomínejte také na negativní scénáře — otestujte, co se stane, když uživatel zadá špatný vstup nebo když služba selže.

Živý příklad a schéma jsou důležitější než dlouhý popis Místo rozsáhlých textů o tom, co endpoint dělá, raději ukažte konkrétní request a response ve formátu JSON. Frontendový vývojář si z příkladu okamžitě přečte strukturu dat, včetně typů polí. Pro opakující se objekty (např. uživatel, objednávka) vytvořte sdílená schémata a odkazujte na ně. Tím se vyhnete duplicitnímu popisu a zajistíte konzistenci, když se model změní. Pomocí nástrojů pro kontraktní testování můžete navíc ověřit, že dokumentace odpovídá skutečné implementaci – to je nejspolehlivější ochrana proti zastarávání.

Jak poznáte, že je vaše pyramida postavená na písku Prvním krokem je revize stávající sady testů. Spočítejte si poměr mezi jednotkovými a end-to-end testy v projektu. Pokud dominují E2E, začněte je přesouvat na nižší úrovně — ale ne mechanicky. Většina byznys logiky se dá ověřit na úrovni jednotkových testů, zatímco E2E si nechte jen pro hlavní uživatelské cesty, jako je přihlášení nebo dokončení objednávky. Při přesouvání se zaměřte na to, co test opravdu ověřuje: jestli kontrolujete chování jedné třídy, je to unit test; jestli spolupracuje více modulů, je to integrační test.

Při zavádění pyramidy se vyhněte dvěma extrémům. První je snaha pokrýt absolutně všechno testy — to vede k tomu, že strávíte více času údržbou testů než vývojem funkcí. Druhý extrém je testovat jen to, co je zrovna v módě, nebo co umíte. Dobrým kompromisem je nastavit si firemní směrnici: jednoduché funkce bez rizika nemusí mít testy vůbec, ale kritické výpočty a platební toky ano. Pak se vyplatí investovat do měření pokrytí, ale ne na úrovni řádků — sledujte pokrytí větví a rozhodovacích podmínek.

Při psaní chybového hlášení se vyvarujte obecných formulací typu „to nefunguje". Konkrétně popište kroky, které jste provedli, a to včetně vstupních dat. Uveďte, na jakém zařízení a v jakém prohlížeči jste pracovali. Přidejte očekávaný výsledek a skutečný výsledek. Tímto způsobem prokážete, že rozumíte struktuře hlášení, což je častý požadavek i na juniorské pozice.

Pamatujte, že pyramida není statická. S tím, jak se mění architektura aplikace, mění se i poměr testů. Na začátku projektu můžete mít více integračních testů, protože ještě nemáte stabilní rozhraní pro mockování. Po pár měsících se hranice ustálí a vy je převedete na jednotkové. Klíčové je pravidelně revidovat testovací sadu: jednou za kvartál se podívejte, které testy nikdy neselhávají, které opakovaně vyžadují opravy a které už neodpovídají aktuálnímu chování systému. Testy, které nikdo nespouští nebo jim nikdo nerozumí, jsou horší než žádné — dávají falešný pocit bezpečí.