Proč stovky UI testů nenahradí dobré API testy
Tým často začne s automatizací tam, kde aplikaci vidí – v prohlížeči. S rostoucím počtem end-to-end testů však přibývá doba běhu, údržba i náhodná selhání. Sada potom neposkytuje zpětnou vazbu tak rychle, jak tým před releasem potřebuje.
V čem je problém
Testování přes rozhraní patří zpravidla mezi nejpomalejší a nejnáročnější způsoby ověřování obchodní logiky.
Je pomalejší. Každý test musí spustit prohlížeč, načíst stránku, počkat na vykreslení a projít několik obrazovek. Přímý API test tyto kroky vynechá, a proto bývá při stejné kontrole výrazně rychlejší.
Má více důvodů k selhání. Test přes rozhraní závisí na struktuře HTML, animacích, cookie liště i načasování načítání. Pokud jsou výsledky často falešně negativní, tým jim postupně přestane důvěřovat.
Hůře ukazuje příčinu. Když UI test selže u objednávky, ukáže, že nákupní cesta nefunguje, ale diagnostika musí projít více vrstvami. API test dokáže přesněji určit endpoint, vstup a odpověď, u kterých problém nastal.
Nepokryje všechny vstupy. Přes rozhraní obtížně ověříte, zda endpoint zpřístupní cizí objednávku, co udělá server se záporným množstvím nebo jak vypadá odpověď při chybějícím oprávnění. Formulář takový požadavek obvykle ani neodešle, ale server ho přesto musí správně zpracovat nebo odmítnout.
Jak to řešíme
Těžiště testů přesouváme pod vrstvu UI. Obchodní logiku – správnost výpočtů, chybové stavy, autorizační matice, hraniční hodnoty a negativní scénáře – ověřujeme přímo přes API, kde je lze vyvolat spolehlivě a rychle.
Testování přes prohlížeč tím nezaniká. Má jinou úlohu: ověřit, že rozhraní a jednotlivé vrstvy fungují společně – například že zákazník dokončí přihlášení, nákup nebo platbu. Počet takových scénářů volíme podle rizika; nejde o pevné pravidlo ani konkrétní počet testů.
Rychlé kontroly API mohou běžet při každé změně, zatímco pomalejší end-to-end scénáře lze spouštět podle rizika. Tým tak dostane dřívější zpětnou vazbu, aniž by přišel o kontrolu klíčových zákaznických cest.
Pokud už pro testování webu používáte Playwright, můžeme API testy psát přímo v něm – běží ve stejné konfiguraci a zobrazují se ve stejném reportu, takže tým nemusí sledovat dvě místa. Stejně dobře poslouží Python s pytestem nebo Bruno; nástroj vybíráme podle vašeho stacku, nikoli podle toho, co máme rádi.
Co z toho máte
Rychlejší zpětnou vazbu, stabilnější výsledky a chybu nalezenou blíže jejímu zdroji. Frekvenci běhů si tým nastaví podle délky sady a významu jednotlivých kontrol.
Snížit se může také údržba. Pokud redesign nemění kontrakt API, testy na vrstvě API obvykle není nutné upravovat, zatímco testy navázané na prvky stránky změnu pocítí.
Pokud už rozsáhlou UI sadu máte, nezahazujeme ji. Projdeme, co z ní dává smysl přesunout níže, a ponecháme pouze scénáře, které je opravdu nutné ověřit přes prohlížeč.
Další krok
Pokud vaše sada trvá příliš dlouho, sepište si nejpomalejší scénáře a označte logiku, kterou lze ověřit bez prohlížeče. Návrh rozdělení můžete projít během nezávazné konzultace; více informací najdete také na stránce API testy.