Základní chybou je odpovídat okamžitě konkrétním datem. Zkuste místo toho říct: „Potřebuji si projít zadání a ověřit kapacitu, do dvou hodin vám pošlu odhad s tím, co může ovlivnit termín." Tím získáte čas na reálné zhodnocení a zároveň ukazujete, že k problému přistupujete zodpovědně. Pokud odpovíte hned, máte tendenci vycházet z prvního dojmu a podcenit skryté závislosti – a přesně tady vznikají pozdější problémy.<br>
<br>
<br>
<br>
Při návrhu testů platí jednoduché pravidlo: nejdříve si odpovězte, co se může reálně rozbít. Pokud je riziko chyby v logice podmínek, použijte jednotkový test. Pokud je riziko v propojení s databází, souborovým systémem nebo cizí službou, integrační test je na místě. Typickou chybou je psát integrační test na všechno, co se dá, a pak trávit hodiny laděním prostředí. Druhým extrémem je jednotkové testy „nafukovat" tak, aby simulovaly vše, což vede k těžko udržovatelným mockům a testům, které neodrážejí realitu.<br>
<br>
<br>
<br>
Pokud se budete držet těchto zásad, zjistíte, že testování API přestane být chaotické. Přestanete lovit chyby v adresách a začnete se věnovat skutečné logice rozhraní. Až narazíte na problém, budete vědět, kde ho hledat a jak ho opravit. To je hlavní přínos, který vám Postman nabídne, pokud ho používáte systematicky.<br>
<br>
<br>
<br>
Nejčastější past: kombinace licencí a závislostí Při výběru licence nezapomeňte na knihovny a balíčky, které váš projekt používá. Pokud je váš kód postaven na něčem pod GPL, vaše dílo se může stát odvozeným a musí být také pod GPL. To může být problém, pokud chcete použít permisivní licenci. Před finálním rozhodnutím si projděte všechny závislosti a zjistěte, jaké licence mají. Nástroje jako automatické skenery závislostí vám pomohou, ale stejně musíte rozumět tomu, co znamená „odvozené dílo" v kontextu vašeho kódu.<br>
<br>
<br>
<br>
Růst codebase s sebou přináší nejen nové funkce, ale i rostoucí tlak na testovací strategii. Zpočátku vám stačí rychlé jednotkové testy, které ověřují izolované metody. Jakmile ale začnete měnit rozhraní mezi moduly, zjistíte, že vám unikají chyby, které se projeví až při propojení komponent. Klíčem není držet se dogmatického poměru 70:30, ale umět rozpoznat, kdy který typ testu přináší nejvyšší hodnotu za rozumné náklady.<br>
<br>
<br>
<br>
Když narazíte na test, který potřebuje data z předchozího požadavku, uložte si je do proměnné. Například po přihlášení si z odpovědi vytáhnete token a uložíte ho do prostředí. Pak ho použijete v autorizační hlavičce dalších požadavků. Tento postup je standardní a ušetří vám ruční kopírování. Pozor ale na to, že proměnná může být prázdná, pokud předchozí požadavek selže. Proto si v testech ověřte, že se hodnota skutečně nastavila, než ji začnete používat.<br>
<br>
<br>
<br>
<span style="font-weight: bold;">Jednotkové testy jsou vaším</span> každodenním nástrojem pro rychlou zpětnou vazbu. Testují jednu třídu, jednu funkci, jeden algoritmus. Jsou stabilní, běží v milisekundách a přesně řeknou, kde se něco rozbilo. Jejich slabinou je, že neodhalí problémy v integraci – špatně nastavenou konfiguraci, chybějící validaci dat mezi službami nebo neočekávané pořadí volání. Pokud je jediným typem testů ve vašem projektu, začnete časem potřebovat bezpečnostní síť na vyšší úrovni.<br>
<br>
<br>
<br>
Než začnete psát první test, vytvořte si v Postmanu prostředí. Bez něj budete neustále přepisovat adresy a přihlašovací údaje, což vede k chybám. Prostředí vám umožní definovat proměnné, na které se pak odkazujete pomocí dvojitých složených závorek. Typicky tam patří základní URL, klíče, identifikátory nebo tokeny. Díky tomu stačí změnit jednu hodnotu a celá kolekce testů začne běžet proti jinému serveru.<br>
<br>
<br>
<br>
Prakticky doporučuji rozdělit testy do dvou vrstev podle rychlosti. Jednotkové testy spouštějte při každé změně kódu, měly by běžet pod deset sekund. Integrační testy zařaďte do samostatné fáze – ideálně při pushnutí do sdíleného repozitáře nebo v nočním běhu. Tím zajistíte, že vývojáři mají rychlou zpětnou vazbu při psaní kódu, ale zároveň se před nasazením ověří kritické scénáře. Důležité je, aby integrační testy byly deterministické – měly by běžet proti izolovanému prostředí, které je před každým během znovu vytvořeno.<br>
<br>
<br>
<br>
Když zveřejňujete vlastní kód jako open source, první otázka zní: jakou licenci zvolit? Mnozí sáhnou po první, kterou znají, nebo ji zkopírují z jiného projektu. To je častá chyba. Licence totiž neurčuje jen to, co smí dělat ostatní, ale také co smíte dělat vy. Špatně zvolená licence může znemožnit komerční využití vašeho kódu, nebo naopak umožnit jiným, aby si váš kód přivlastnili bez jakýchkoli závazků.
