Mocks, stubs, fakes och emulatorer: testa API-anrop med kodningsagenter

När din kod anropar ett API behöver du ett sätt att testa det utan att vänta på att det verkliga API:et ska misslyckas. Du har 5 typer av ersättare att välja mellan. Folk använder begreppen ganska fritt, så här använder den här artikeln dem:

  • Stub: en intern ersättning för HTTP-klienten eller SDK-anropet som returnerar ett fördefinierat svar. Den är snabb och repeterbar och testar din logik bakom svaret du skrev.
  • Mock: en stub som också registrerar hur din kod anropade den, så att testet kan kontrollera anropen. Den når så långt som en stub.
  • Simulerad server: en liten fungerande server, ofta minnesintern, som appen anropar via HTTP i stället för det verkliga API:et. Den testar din HTTP-klient, men du måste peka appen på dess URL.
  • Emulator: en lokal version av en tjänst, som vanligtvis publiceras av tjänstens ägare, som fungerar som den riktiga tjänsten för de åtgärder som den stöder. Kontrollera vilka begränsningar och fel det omfattar innan du förlitar dig på det för felhantering.
  • Intercepterande proxy: finns i nätverket mellan din app och API:et. Din app anropar den verkliga URL:en och proxyn släpper igenom förfrågningar eller svarar på några av dem med det svar som du definierar. Din app måste skicka sin trafik via proxyn och, för HTTPS, lita på proxyns certifikat.

Testa kod som anropar ett API

Approach Vad det testar Vad den behöver Precis när
Stub eller mock Din logik för ett specifikt svar Ditt testramverk Du testar affärslogik, parsning och felgrenar i enhetstester
Fejkserver Din HTTP-klient och serialisering En bas-URL-inställning eller konfigurationsinställning i din app API:et finns inte än, eller så behöver du en stabil serverdel för UI-arbete
Emulator Beteende nära den verkliga tjänsten för åtgärder som stöds En annan ändpunkt eller anslutningssträng Tjänstens ägare skickar en, och du utvecklar offline
Verkligt API med ett testkonto På riktigt Inloggningsuppgifter, kvot och pengar Du verifierar huvudsökvägen ända till ände
interceptande proxy Din app på verkliga URL:er, inklusive SDK-återförsök och svarshuvuden Proxyinställningar och tillit till certifikat Du testar felutfall, begränsningar och svarstider utan att ändra din app

Du behöver mer än 1 av dessa. Stubs håller dina enhetstester snabba. En proxy visar vad hela appen gör när det verkliga API:et fungerar felaktigt. Mer information om hur de två passar ihop finns i Dev Proxy jämfört med enhetstester.

Vad kodningsagenter skapar

När du ber en kodningsagent att göra så att appen hanterar API-fel och visar att den fungerar, väljer den en stand-in åt dig. Vi ville veta vilken, så vi körde ett test med 3 kodningsagenter (210 körningar). Uppgifterna använde fraser som "hantera hastighetsbegränsning korrekt och visa mig att det fungerar", "verifiera det utan att spendera pengar på riktiga API-anrop" och "kör detta utan en OpenAI-nyckel eller en Internetanslutning".

  • I 76 % av de 140 körningar som efterfrågade fungerande kod skapade agenten denna lösning för hand: fetch-stubbar, httpx.MockTransport, eller en tillfällig HTTP-server.
  • I 61 av de 105 körningarna på appar som anropar GitHub, OpenAI eller ett väder-API lade agenten till en bas-URL eller konfigurationsflagga till appen så att den kunde nå sin fejkade tjänst.
  • I de 75 körningar där det verkliga API:et var tillgängligt och uppmaningen inte uteslöt det, testade 0 körningar appen på dess verkliga API-URL.

Stubs är ett rimligt val för enhetstester. Klyftan är vad de utelämnar. Agentens stub returnerar det fel som agenten förväntade sig, vilket kanske inte matchar vad API:et skickar. Och omkopplaren som lades till för att nå de falska skeppen med din app.

Så här arbetar du med agentens tester

  • Behåll stubbarna för din logik. De är snabba och testar brancherna som agenten skrev.
  • Begär det verkliga felformatet. Be agenten att basera varje simulerat fel på leverantörens dokumenterade statuskoder, rubriker och fält i brödtexten. En bare 429 testar inte att appen läser retry-after eller skiljer ett faktureringsfel från en hastighetsbegränsning.
  • Granska ändringar som lagts till för tester. Om agenten bara lägger till en grundläggande URL-inställning så att testerna kan nå en fejk/mock, ska du avgöra om du vill ha den inställningen i din produktionskod.
  • Kör appen en gång på verkliga URL:er med simulerade fel. Innan du skickar kontrollerar du vad appen som körs, dess SDK och dess återförsöksprincip gör med API:ets egna fel. Om du vill granska agentens felhantering steg för steg, se Så här verifierar du felhantering som din kodningsagent har skrivit.

Prova det i din app

Dev Proxy är en avlyssningsproxy för utveckling. Den returnerar de svar som du definierar för de URL:er som appen redan anropar, utan ändringar i appens kod. Aktivera MockResponsePlugin i din config, 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"
  }
}

Definiera sedan svaret i mocks.json. Den här returnerar 503 med en Retry-After rubrik för prognosslutpunkten:

{
  "$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"
        }
      }
    }
  ]
}

Starta Dev Proxy och kör appen som vanligt:

devproxy --config-file devproxyrc.json

Begäranden som inte matchar en mock går till det verkliga API:et. När du behöver en serverdel som inte finns ännu simulerar CrudApiPlugin ett CRUD-API med minnesintern data. Om du vill låta en del av begärandena misslyckas slumpmässigt i stället för varje gång, se Testa appen med slumpmässiga fel. Information om hur du installerar Dev Proxy finns i Set up Dev Proxy.

Nästa steg

Falska svar

Se även

  • Uppdaterades senast