Mocky, stuby, faky a emulátory: testování volání rozhraní API pomocí agentů kódování

Když kód volá rozhraní API, potřebujete způsob, jak ho otestovat bez čekání na selhání skutečného rozhraní API. Máte na výběr z 5 druhů zástupných prvků. Lidé používají názvy nepřesně, takže takto je tento článek používá:

Stub: náhrada v rámci procesu za volání klienta HTTP nebo sady SDK, která vrací předem připravenou odpověď. Je to rychlé a opakovatelné a testuje vaši logiku v odpovědi, kterou jste napsali.
Mock: zástupný kód, který také zaznamenává, jak jej váš kód volal, aby test mohl kontrolovat volání. Dosáhne až ke stubu.
Falešný server: malý funkční server, často v paměti, který vaše aplikace volá přes HTTP místo skutečného rozhraní API. Otestuje vašeho HTTP klienta, ale aplikaci musíte nasměrovat na její adresu URL.
Emulátor: místní verze služby, obvykle publikovaná vlastníkem služby, která se chová jako skutečná verze pro operace, které podporuje. Než se na něj budete spoléhat při zpracování chyb, zkontrolujte, jaká omezení a selhání pokrývá.
Interceptující proxy server: nachází se v síti mezi vaší aplikací a rozhraním API. Vaše aplikace volá skutečnou adresu URL a proxy server předává požadavky nebo na některé z nich odpoví vámi definovanou odpovědí. Vaše aplikace musí posílat svůj provoz přes proxy server a v případě HTTPS důvěřovat certifikátu proxy serveru.

Testování kódu, který volá rozhraní API

Approach	Co testuje	Co je potřeba	Právě když
Zástupná procedura nebo mock	Vaše logika pro konkrétní odpověď	Váš testovací framework	Testujete obchodní logiku, parsování a větve chyb v jednotkových testech.
Falešný server	Váš klient HTTP a serializace	Nastavení základní adresy URL nebo přepínač konfigurace v aplikaci	Rozhraní API ještě neexistuje nebo potřebujete stabilní back-end pro práci s uživatelským rozhraním.
Emulator	Chování blízko skutečné služby pro podporované operace	Jiný koncový bod nebo připojovací řetězec	Vlastník služby dodává jednu verzi a vy vyvíjíte offline.
Skutečné rozhraní API s testovacím účtem	Originál	Přihlašovací údaje, kvóta a peníze	Ověříte hlavní cestu od začátku do konce.
Interceptující proxy server	Vaše spuštěná aplikace na skutečných adresách URL, včetně opakovaných pokusů SDK a hlaviček odpovědí	Nastavení proxy serveru a důvěryhodnost certifikátu	Testujete selhání, limity a latenci, aniž byste měnili svou aplikaci.

Potřebujete více než 1 z nich. Stuby udržují jednotkové testy rychlé. Proxy vám ukáže, co celá aplikace dělá, když se skutečné rozhraní API chová nesprávně. Další informace o tom, jak tyto dvě věci spolu souvisejí, najdete v tématu Dev Proxy vs unit tests.

Co vytvářejí agenti pro kódování

Když požádáte kódovacího agenta, aby vaše aplikace zpracovávala selhání rozhraní API a ukázala, že to funguje, vybere za vás zástupný objekt. Chtěli jsme vědět, který z nich to byl, takže jsme spustili test se 3 kódovacími agenty (210 spuštění). Úlohy obsahovaly formulace, jako je například "správně zpracovat omezování rychlosti a ukázat mi, že funguje", "ověřte to bez výdajů na skutečná volání rozhraní API" a "spusťte to bez klíče OpenAI nebo připojení k internetu".

V 76 % ze 140 spuštění, která požádala o funkční kód, agent sestavil selhání ručně: stuby pro fetch, httpx.MockTransport, nebo jednorázový HTTP server.
V 61 ze 105 spuštění aplikací, které volají GitHub, OpenAI nebo rozhraní API pro počasí, agent přidal do aplikace základní adresu URL nebo konfigurační přepínač, aby se aplikace mohla připojit k jeho falešné službě.
V 75 spuštěních, kde bylo skutečné rozhraní API k dispozici a výzva ho nevyloučila, 0 jich otestovalo aplikaci na jeho skutečné adrese URL rozhraní API.

Stuby jsou rozumnou volbou pro testy jednotek. Rozdíl je v tom, co vynechají. Zástupný kód agenta vrátí chybu, kterou agent očekával, což nemusí odpovídat tomu, co rozhraní API odesílá. A přepínač, který přidal pro přístup k falešným lodím pomocí vaší aplikace.

Jak pracovat s testy vašeho agenta

Ponechte stuby pro vaši logiku. Jsou rychlé a testují větve, které agent napsal.
Požádejte o skutečný formát chybové zprávy. Požádejte agenta, aby založil každou simulovanou chybu na dokumentovaných stavových kódech, hlavičkách a textových polích zprostředkovatele. Samotný kód 429 neotestuje, že vaše aplikace čte retry-after nebo rozliší chybu fakturace od omezení rychlosti.
Zkontrolujte přidané přepínače pro testy. Pokud agent přidá jenom základní nastavení adresy URL, aby testy mohly dosáhnout falešného kódu, rozhodněte se, jestli chcete toto nastavení v produkčním kódu.
Spusťte aplikaci jednou na skutečných adresách URL se simulovanými chybami. Před odesláním zkontrolujte, co má spuštěná aplikace, její sada SDK a její zásada opakování dělat s vlastními chybami rozhraní API. Pokud chcete zkontrolovat zpracování chyb agenta krok za krokem, přečtěte si, jak ověřit zpracování chyb, které napsal váš agent pro psaní kódu.

Vyzkoušejte si ji v aplikaci

Dev Proxy je zachytávání proxy pro vývoj. Vrátí odpovědi, které definujete pro adresy URL, které aplikace už volá, beze změn kódu vaší aplikace. V konfiguraci povolte MockResponsePlugin: devproxyrc.json

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/rc.schema.json",
  "plugins": [
    {
      "name": "MockResponsePlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll",
      "configSection": "mocksPlugin"
    }
  ],
  "urlsToWatch": [
    "https://api.contoso.com/*"
  ],
  "mocksPlugin": {
    "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/mockresponseplugin.schema.json",
    "mocksFile": "mocks.json"
  }
}

Pak definujte odpověď v mocks.json. Tento vrací 503 s hlavičkou Retry-After pro koncový bod předpovědi:

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/mockresponseplugin.mocksfile.schema.json",
  "mocks": [
    {
      "request": {
        "url": "https://api.contoso.com/v1/forecast*",
        "method": "GET"
      },
      "response": {
        "statusCode": 503,
        "headers": [
          {
            "name": "Retry-After",
            "value": "10"
          }
        ],
        "body": {
          "error": "Service unavailable"
        }
      }
    }
  ]
}

Spusťte Dev Proxy a spusťte aplikaci obvyklým způsobem:

devproxy --config-file devproxyrc.json

Požadavky, které neodpovídají napodobení, přejdou do skutečného rozhraní API. Pokud potřebujete back-end, který ještě neexistuje, crudApiPlugin simuluje rozhraní CRUD API s daty v paměti. Pokud chcete, aby sdílená složka požadavků byla náhodně neúspěšná, a ne pokaždé, přečtěte si téma Testování aplikace s náhodnými chybami. Pokud chcete nainstalovat Dev Proxy, přečtěte si téma Nastavení Dev Proxy.

Další kroky

Simulované odpovědi

Viz také

Váš názor

Byla tato stránka užitečná?

Poslední aktualizace v 2026-10-05