Mock, sandbox nebo reálná služba: jak testovat externí integrace
Externí služba, například platební brána, dopravce nebo partnerské API, může být během testu pomalá či nedostupná nebo může vyvolat skutečný vedlejší účinek. Nahrazení mockem zrychlí zpětnou vazbu, ale nepotvrdí, že si oba systémy opravdu rozumějí. Dobrá strategie proto nehledá jediného vítěze: každou vrstvu používá pro jinou otázku.
Proč jedna testovací vrstva nestačí
Mock je řízená náhrada externí služby, kterou ovládá testovací tým. Na požadavek vrátí předem připravenou odpověď, zpoždění nebo chybu. Test tak spolehlivě vyvolá překročení časového limitu, neplatná data či nedostupnost, aniž by čekal na skutečný problém u dodavatele.
Mock je rychlý a deterministický, tedy při stejném vstupu připraví stejnou situaci. Dokazuje však pouze chování aplikace vůči naprogramované představě rozhraní. Pokud obsahuje staré pole nebo chybný stavový kód, test může projít, i když reálné propojení selže. Praktické chybové scénáře popisuje také přehled toho, co testovat na API.
Sandbox je testovací prostředí provozované poskytovatelem. Komunikujete s jeho skutečným softwarem a používáte jeho autentizační mechanismy, ale pracujete s testovacími účty a nevyvoláváte skutečné produkční dopady. Hodí se pro ověření formátu požadavků, přístupových údajů, návratových volání a podporovaných stavů.
Sandbox nemusí mít stejná data, kapacitu, časování, antifraud pravidla ani všechny funkce jako produkce. Některé výsledky může poskytovatel pouze simulovat. U plateb proto potřebujete znát hranice testovacího režimu platební brány, nikoli považovat úspěšnou transakci v sandboxu za důkaz celého ostrého procesu.
Reálná služba poskytuje nejsilnější důkaz, že aktuální konfigurace a síťové propojení fungují v kontrolovaném scénáři. Přináší však nejvíce omezení: může měnit data, posílat zprávy, spotřebovat limit, vytvořit objednávku nebo selhat kvůli problému mimo váš produkt. Takový test má mít omezený rozsah, být bezpečný a dohodnutý s provozem a spouštět se jen s přiměřenou četností.
Rozhodujte podle otázky, ne podle zdánlivého realismu
Nejprve si pojmenujte, co má výsledek prokázat:
- Jak aplikace reaguje na chybu nebo pomalou odpověď? Použijte mock, protože situaci vyvoláte cíleně a opakovaně.
- Posíláme požadavek ve tvaru, který poskytovatel přijímá? Ověřte integraci v sandboxu a přidejte kontrolu kontraktu.
- Odpovídají obě strany stejné dohodě? Kontraktní test porovná očekávání klienta s chováním poskytovatele v pokrytém rozsahu.
- Funguje kritická cesta s aktuální ostrou konfigurací? Zvažte malý nedestruktivní test reálné služby nebo bezpečný produkční monitoring.
Do volby patří také vlastnictví testovacích dat, povolené vedlejší účinky, limity volání, dostupnost prostředí a čas, kdy tým potřebuje výsledek. Nejrealističtější test není automaticky nejlepší pro každou změnu.
Kombinovaná strategie omezuje slepá místa
Začněte širokou sadou proti mocku. Pokryjte úspěch, známé chyby, překročení časového limitu, neplatnou odpověď, opakování požadavku a chování po částečném výsledku. Tyto scénáře mohou běžet často a nezávisle na dostupnosti partnera.
Mock pak ukotvěte ve smlouvě o rozhraní. Schéma OpenAPI může ověřit tvar zpráv; spotřebitelem řízený kontrakt zaznamená konkrétní očekávání klienta. Nástroje jako Pact umožňují ověřit zaznamenané interakce vůči implementaci poskytovatele. Kontrakt ale zná jen pokryté interakce a nenahrazuje celou integrační strategii.
V sandboxu ponechte reprezentativní úspěšný tok a důležité chybové stavy, které poskytovatel podporuje. Nakonec přidejte pouze nezbytné kontroly reálné služby. Výsledek označte tak, aby tým rozeznal chybu produktu od výpadku cizí závislosti. Stejné rozlišení pomáhá při stabilizaci náhodně selhávajících testů.
Na co si dát pozor
Nevytvářejte mock zkopírováním jediné úspěšné odpovědi bez pravidel. Zachovejte povinná pole, typy, stavové přechody a chyby, na kterých aplikace závisí. Při změně kontraktu upravte nejdříve dohodu a potom mock i testy.
Produkční test nesmí bez kontroly rozesílat e-maily zákazníkům, účtovat platby ani měnit sklad. Použijte vyhrazené účty, rozpoznatelná data, idempotentní operace, pokud je rozhraní podporuje, a dohodnutý úklid. Ani úspěšný bezpečný průchod neprokazuje všechny stavy produkce.
Co tím získáte
- Rychlou zpětnou vazbu pro velký počet chybových scénářů.
- Včasnější upozornění, když se mock a reálné rozhraní začnou rozcházet.
- Menší závislost běžných testů na dostupnosti cizí služby.
- Přiměřený důkaz skutečného propojení bez zbytečných ostrých vedlejších účinků.
Další krok
Sepište externí závislosti a u každé si položte tři nejdůležitější otázky: jakou chybu musí aplikace zvládnout, jaký kontrakt musí zachovat a co potřebuje potvrdit skutečné propojení. Ke každé otázce přiřaďte nejnižší vrstvu, která ji dokáže důvěryhodně zodpovědět, a zdokumentujte zbývající omezení.