Kdy je čas oddělit jednotkové testy od integračních?

Zkus si projít jeden konkrétní případ od začátku do konce. Vyber API, které nevyžaduje platbu ani složité schvalování, a zavolej jeden koncový bod, který vrací seznam nebo detail. Výsledek si ulož do souboru a porovnej, co dokumentace slibuje a co skutečně přišlo. Tím zjistíš, jak přesně odpověď vypadá, jaké má klíče a co znamenají hodnoty null. Teprve pak přidej druhé volání, které používá data z prvního. Takhle se naučíš řetězení požadavků, což je základ většiny reálné práce s API.

Prvním kritériem je způsob, jakým chcete, aby váš kód žil dál. Pokud chcete, aby ho přijaly co největší firmy a integrovaly ho do svých produktů, je permisivní licence prakticky nutností. Právní oddělení velkých společností často zakazují jakýkoli copyleft, protože by je nutil otevírat vlastní kód. Naopak pokud je pro vás klíčové, aby všechny vylepšení zůstala veřejná, copyleft je jediná cesta, jak to vymoci. Bez copyleftu může kdokoli vzít váš kód, vylepšit ho a prodávat jako uzavřený produkt, aniž by vám něco vrátil.

Portfolio rozhoduje, ne počet certifikát

Dynamická data v aplikacích znamenají, že se obsah mění v čase – ať už jde o časové značky, náhodné hodnoty, nebo data závislá na aktuálním stavu systému. Testovat takové aplikace vyžaduje jiný přístup než u statických dat. Nejde jen o to ověřit, zda se něco zobrazí, ale zda se to zobrazí správně v každém okamžiku a za každých podmínek.

Oddělte sady i v běhu, ne jen ve jménech Přejmenovat složky nestačí. Rozdělte spouštění tak, aby jednotkové testy běžely při každé změně a integrační až před mergem nebo v CI na samostatném kroku. V praxi to znamená dvě konfigurace runneru, dvě sady závislostí a odlišné timeouty. Jednotkové testy mají běžet v řádu sekund, integrační mohou trvat minuty, ale musí být deterministické. Pokud integrační test občas spadne a občas projde, není to integrační test, ale dluh.

Typická chyba je sdílený stav mezi testy. Statická cache, singleton připojení nebo testovací databáze, kterou jeden test zapíše a druhý čte, vytváří závislosti, které se projeví až ve chvíli, kdy se sada rozroste. Izolujte data na úrovni transakcí nebo schématu pro každý test. Není to zdarma, ale je to levnější než ladit náhodné pády v CI.

Volba klíče rozhoduje o tom, zda limit omezí útočníka, nebo vaše uživatele. IP adresa je nejjednodušší, ale za NATem nebo proxy může jedna IP skrývat stovky lidí. Pokud aplikace běží za reverzní proxy, musíte správně nastavit důvěryhodnost hlaviček, jinak budete všechny požadavky vidět z jedné adresy. U přihlášených uživatelů je lepší klíčovat podle ID účtu nebo tokenu. U veřejných endpointů kombinujte IP s cestou. Okno volte podle chování – pro přihlašování stačí krátké okno v řádu minut, pro API třeba delší. Vyhněte se pevnému oknu, které se resetuje v celou minutu, protože to vytváří nárazové špičky. Plynulé klouzavé okno nebo token bucket lépe rozloží zátěž v čase.

Než začneš psát kód, zjisti si dvě věci: kde je dokumentace a jestli potřebuješ přístupový klíč. Většina API funguje tak, že pošleš požadavek na konkrétní adresu a dostaneš odpověď ve formátu JSON. Otevři si dokumentaci a najdi sekci, která se jmenuje nějak jako „authentication" nebo „getting started". Tam bývá přesně popsané, jak klíč získat a jak ho posílat. U některých služeb stačí klíč vložit do hlavičky požadavku, jinde se podepisuje každý požadavek zvlášť. To druhé je složitější a pro první pokusy se tomu vyhni.

Jak pracovat s náhodou a závislostmi Dalším problémem jsou náhodná data. Pokud aplikace generuje náhodná čísla, ID nebo řetězce, test nesmí záviset na konkrétní hodnotě. Místo toho ověřujte vlastnosti – formát, rozsah, unikátnost. Nebo náhodu nahraďte deterministickým generátorem, který v testovacím prostředí vrací vždy stejnou posloupnost. Tím dosáhnete reprodukovatelných výsledků.

Častou chybou je testování proti produkční databázi nebo živému API. Dynamická data se mohou kdykoli změnit a testy pak selhávají z nesprávných důvodů. Vždy používejte oddělené testovací prostředí s vlastní sadou dat, kterou máte plně pod kontrolou. Pokud to nejde, alespoň data před testem zaznamenejte a po testu obnovte.

Nakonec počítejte s tím, že hranice se budou posouvat. Co bylo dříve integrační test, se po zavedení kontraktů a fake serverů může stát jednotkovým. Pravidelně sadu procházejte a přesouvejte testy mezi vrstvami. Cílem není dokonalá kategorizace, ale předvídatelná zpětná vazba: rychlé jednotkové testy pro vývojáře a pomalejší integrační pro ověření, že spolu části skutečně mluví.