Mocks, stubs, fakes en emulators: API-aanroepen testen met codeeragenten

Wanneer uw code een API aanroept, hebt u een manier nodig om deze te testen zonder te hoeven wachten tot de echte API faalt. U hebt 5 soorten stand-ins waaruit u kunt kiezen. Mensen gebruiken de namen door elkaar, dus in dit artikel gebruiken we ze als volgt:

  • Stub: een in-process vervanging voor uw HTTP-client of SDK-aanroep die een standaardantwoord retourneert. Het is snel en herhaalbaar en test de logica van het antwoord dat u hebt geschreven.
  • Mock: een stub die ook registreert hoe uw code deze heeft aangeroepen, zodat uw test de aanroepen kan controleren. Het reikt tot een stub.
  • Mockserver: een kleine werkende server, vaak in het geheugen, die uw app aanroept via HTTP in plaats van de echte API. Het test uw HTTP-client, maar u moet uw app naar de URL laten verwijzen.
  • Emulator: een lokale versie van een service, meestal gepubliceerd door de eigenaar van de service, die zich gedraagt als de echte versie voor de bewerkingen die worden ondersteund. Controleer welke limieten en storingen het dekt voordat u erop vertrouwt voor foutafhandeling.
  • Onderscheppende proxy: bevindt zich in het netwerk tussen uw app en de API. Uw app roept de echte URL aan en de proxy geeft aanvragen door of beantwoord enkele aanvragen met het antwoord dat u definieert. Uw app moet het verkeer via de proxy verzenden en voor HTTPS het certificaat van de proxy vertrouwen.

Hoe test je code die een API aanroept?

Approach Wat wordt getest Wat het nodig heeft Juist wanneer
Stub of mock-object Uw logica voor een specifiek antwoord Uw testframework Je test bedrijfslogica, parserlogica en foutafhandelingspaden in eenheidstests
Dummyserver Uw HTTP-client en serialisatie Een basis-URL-instelling of configuratieswitch in uw app De API bestaat nog niet of u hebt een stabiele back-end nodig voor ui-werk
Emulator Gedrag dat dicht bij de echte service ligt voor ondersteunde bewerkingen Een ander eindpunt of verbindingsreeks De eigenaar van de service levert er een en u ontwikkelt offline
Echte API met een testaccount Het origineel Inloggegevens, quota en geld U verifieert het hoofdpad van begin tot eind
Proxy onderscheppen Uw draaiende app op echte URL's, inclusief SDK-herpogingen en antwoordheaders Proxy-instellingen en certificaatvertrouwen U test foutscenario’s, limieten en latentie zonder uw app te wijzigen

U hebt meer dan 1 van deze nodig. Stubs zorgen ervoor dat uw eenheidstests snel worden uitgevoerd. Een proxy laat zien wat de hele app doet wanneer de echte API zich misdraagt. Zie Dev Proxy versus eenheidstests voor meer informatie over hoe de 2 bij elkaar passen.

Wat coding agents bouwen

Wanneer u een coderingsagent vraagt om api-fouten in uw app af te handelen en te laten zien dat deze werkt, kiest deze een vervanger voor u. We wilden weten welke, dus we hebben een test uitgevoerd met 3 coderingsagents (210 uitvoeringen). De taken gebruikten formuleringen zoals 'ga correct om met rate limiting en laat me zien dat het werkt', 'verifieer het zonder geld uit te geven aan echte API-calls' en 'voer dit uit zonder een OpenAI-sleutel of een internetverbinding'.

  • In 76% van de 140 uitvoeringen waarin om werkende code werd gevraagd, heeft de agent de fout handmatig gebouwd: fetch-stubs, httpx.MockTransport, of een wegwerp-HTTP-server.
  • In 61 van de 105 runs op apps die GitHub, OpenAI of een weer-API aanroepen, heeft de agent een basis-URL of configuratieswitch toegevoegd aan de app, zodat deze de nepversie ervan kon bereiken.
  • In de 75 uitvoeringen waar de echte API beschikbaar was en de prompt deze niet heeft uitgesloten, heeft 0 de app getest op de echte API-URL.

Stubs zijn een redelijke keuze voor eenheidstests. De kloof is wat ze weglaten. De stub van de agent retourneert de fout die de agent verwachtte, die mogelijk niet overeenkomt met wat de API verzendt. En de schakelaar die is toegevoegd om de nepschepen via uw app te bereiken.

Werken met de tests van uw agent

  • Houd de stubs voor uw logica. Ze zijn snel en ze testen de branches die de agent heeft geschreven.
  • Vraag naar de echte foutindeling. Vraag de agent om elke gesimuleerde fout te baseren op de gedocumenteerde statuscodes, headers en bodyvelden van de provider. Een kale 429-statuscode test niet of uw app retry-after leest of een factureringsfout van een snelheidslimiet kan onderscheiden.
  • Reviewschakelaars toegevoegd voor tests. Als de agent alleen een basis-URL-instelling toevoegt, zodat tests een mock kunnen bereiken, moet u beslissen of u die instelling in uw productiecode wilt gebruiken.
  • Voer de app eenmaal uit op echte URL's met gesimuleerde fouten. Controleer voordat u uitbrengt wat de actieve app, de SDK en het retrybeleid doen met de eigen fouten van de API. Als u de foutafhandeling van de agent stapsgewijs wilt bekijken, raadpleegt u Hoe u de foutafhandeling van de coderingsagent controleert.

Probeer het in uw app

Dev Proxy is een interceptieproxy voor ontwikkeling. Het retourneert de antwoorden die u definieert voor de URL's die uw app al aanroept, zonder wijzigingen in de code van uw app. Schakel MockResponsePlugin in uw configuratie in, 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"
  }
}

Definieer vervolgens het antwoord in mocks.json. Deze retourneert 503 met een Retry-After header voor het prognose-eindpunt:

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

Start dev proxy en voer uw app zoals gebruikelijk uit:

devproxy --config-file devproxyrc.json

Aanvragen die niet overeenkomen met een mock, gaan naar de echte API. Wanneer u een backend nodig hebt die nog niet bestaat, simuleert de CrudApiPlugin een CRUD-API met gegevens in het geheugen. Als u een deel van de aanvragen willekeurig wilt laten mislukken in plaats van elke keer, zie Mijn app testen met willekeurige fouten. Zie Dev Proxy instellen om Dev Proxy te installeren.

Volgende stappen 

Gesimuleerde antwoorden

Zie ook

  • Laatst bijgewerkt om