Co testovat na API, i když uživatelské rozhraní funguje
Formulář neumožní odeslat prázdné jméno a cizí objednávka se v seznamu nezobrazí. To však ještě nepotvrzuje, že stejná pravidla vynucuje také server. API může volat mobilní aplikace, partnerská integrace nebo upravený požadavek, který uživatelské rozhraní zcela obejde.
Rozhraní ukazuje především úspěšný scénář
Přes uživatelské rozhraní lze dobře ověřit to, co má fungovat. Hůře se ověřuje to, co fungovat nesmí.
Zkuste přes uživatelské rozhraní odeslat objednávku se záporným množstvím. Formulář ji pravděpodobně nepřijme. Důležité však je, co udělá server, když takový požadavek dostane od jiného klienta nebo v důsledku chybné integrace.
Takové scénáře pokrýváme na úrovni API, kde je lze vyvolat přímo, rychle a opakovatelně.
Autorizační matice
Mezi závažné chyby patří nedostatečné kontroly oprávnění. Koncový bod může ověřit, že je uživatel přihlášený, ale už ne to, zda mu daný záznam patří. V rozhraní se to nemusí projevit, protože odkaz na cizí objednávku se uživateli nezobrazí.
Proto sestavujeme matici: každý důležitý endpoint krát každá role – nepřihlášený uživatel, běžný zákazník, jiný zákazník, obchodník a administrátor. Ověříme nejen to, že správná role projde, ale především to, že nesprávná dostane zamítavou odpověď – a nikoli například prázdnou odpověď se stavem 200.
Validace vstupů a hraniční hodnoty
Server musí každý vstup ověřit nezávisle na kontrole v uživatelském rozhraní. Testujeme chybějící povinná pole, nesprávné datové typy, příliš dlouhé řetězce, neplatné formáty data, hodnoty těsně pod limitem a těsně nad ním, nulu a záporná čísla tam, kde dávají smysl pouze kladná.
Pokud je specifikace OpenAPI aktuální a dostatečně přesná, mohou z ní nástroje odvodit část hraničních a neplatných vstupů. Vygenerované případy však stále doplňujeme o obchodní pravidla, která samotné schéma nezná.
Chybové stavy a negativní scénáře
Chybová odpověď je funkce jako každá jiná a testuje se stejným způsobem. Sledujeme, zda API vrátí správný stavový kód, zda chybová zpráva opravdu vysvětluje problém a zda po neúspěchu nezůstane v databázi polovina záznamu.
Ověřujeme také, jak se systém zachová, když selže něco mimo něj – například když neodpovídá platební brána nebo je nedostupný sklad. V takovém případě použijeme řízenou náhradu odpovědi externí služby označovanou jako mock, pomocí které nasimulujeme výpadek nebo pomalou odpověď. Jinak lze takový scénář otestovat pouze tak, že se počká, až nastane v produkci.
Co z toho máte
Sada pokrývající oprávnění, vstupy a chybové stavy může běžet při každé změně v CI. Při selhání dostane tým konkrétní informaci – například že určitý endpoint přijal záporné množství – namísto obecného hlášení, že nákup nefunguje.
Pro návrh pokrytí je nutné znát očekávané chování rozhraní, uživatelské role a důležitá obchodní pravidla. Aktuální specifikace OpenAPI práci usnadní, ale chybějící části lze doplnit rozhovorem s týmem a ověřením testovacího prostředí. Testy mohou být v Pythonu s pytestem nebo v Brunu podle toho, co vyhovuje technologiím a zkušenostem týmu.
Další krok
Začněte dvěma seznamy: kritické endpointy a požadavky, které musí server odmítnout. Pokud s námi chcete projít priority a negativní scénáře, využijte nezávaznou konzultaci. Více informací o službě najdete na stránce API testy.