Jak testovat REST API: co ověřit a jak testy zapojit do CI/CD
REST API je rozhraní, jehož prostřednictvím si systémy posílají data pomocí HTTP požadavků. Při testu voláme jeho koncové body neboli endpointy a kontrolujeme odpověď, aniž bychom procházeli uživatelským rozhraním. V článku se zaměříme na pravidla typická pro REST a na způsob, jak z kontrol vytvořit udržitelnou testovací sadu.
V čem je problém
Mnoho týmů testuje především prostřednictvím obrazovek aplikace, protože jsou nejblíže tomu, co vidí zákazník. Řadu pravidel aplikace však lze ověřit přímo přes API rychleji a s přesnější informací o příčině chyby.
U REST se navíc snadno přehlédnou věci, které nejsou přes uživatelské rozhraní vůbec vidět: zda endpoint dodržuje sémantiku HTTP metod, zda vrátí správný stavový kód a zda lze požadavek bezpečně zopakovat. Právě zde vznikají chyby, které naruší integraci partnera, přestože v prohlížeči vše vypadá v pořádku.
Co je specifické pro REST
Nad rámec běžných kontrol API ověřujeme věci, které vyplývají přímo z toho, jak má REST fungovat:
- Význam HTTP metod – zda
GETnemění data, opakovanýPUTneboDELETEmá očekávaný výsledek a zda sePOST,PUTiPATCHpoužívají v souladu s návrhem API. - Stavové kódy – zda přijde správný kód (
200,201,204,400,401,403,404,409…), nikoli „vždy 200 a chyba ukrytá v těle“. - Bezpečné opakování požadavků – například zda klient po výpadku sítě nevytvoří druhou platbu nebo objednávku. U operací typu
POSTse to často řeší jedinečným klíčem požadavku označovaným jako idempotency key. - Stránkování, filtrování a řazení – zda se rozsáhlý seznam vrátí po stránkách a parametry opravdu fungují.
- Verzování a zpětná kompatibilita – zda změna API nenaruší stávající klienty; na to navazují kontraktní testy.
- Hlavičky a formát – správný
Content-Typea zpracování chybějící nebo neplatné hlavičky.
Čím a jak to řešíme
Testy mohou být v Pythonu s pytestem, v Brunu nebo v Playwrightu. Výběr závisí na technologiích a zkušenostech týmu. Testovací soubory ukládáme do Gitu, aby byla historie změn viditelná společně se změnami aplikace.
V CI/CD lze spouštět rychlé kontroly při každé změně a rozsáhlejší sadu například před releasem. O tom, které selhání má zastavit nasazení, rozhoduje tým podle rizika. Pokud máte aktuální specifikaci OpenAPI, využijeme ji ke kontrole formátu rozhraní a návrhu části vstupů.
Co z toho máte
- Zpravidla rychlejší zpětnou vazbu než u stejných kontrol přes prohlížeč.
- Chyby ve stavových kódech, opakování požadavků nebo stránkování odhalené přímo na vrstvě REST.
- Přesnější výsledek testu, který týmu pomůže rychleji najít příčinu.
Další krok
Začněte seznamem kritických endpointů, klientů a chyb, které by měly největší dopad. Pokud s námi chcete projít návrh pokrytí, využijte nezávaznou konzultaci.