Mocks, Stubs, Fakes und Emulatoren: Testen von API-Aufrufen mit Codierungs-Agents

Wenn Ihr Code eine API aufruft, benötigen Sie eine Möglichkeit, sie zu testen, ohne darauf zu warten, dass die echte API fehlschlägt. Sie haben fünf Arten von Platzhaltern zur Auswahl. Personen verwenden die Namen locker. Hier erfahren Sie, wie dieser Artikel sie verwendet:

• Stub: Ein In-Process-Ersatz für Ihren HTTP-Client- oder SDK-Aufruf, der eine vordefinierte Antwort zurückgibt. Es ist schnell und wiederholbar und überprüft Ihre Logik in der von Ihnen verfassten Antwort.
• Mock: ein Stub, der auch erfasst, wie Ihr Code es aufgerufen hat, damit Ihr Test die Aufrufe überprüfen kann. Es reicht bis zu einem Stummel.
• Fake-Server: ein kleiner funktionsfähiger Server, häufig im Arbeitsspeicher, den Ihre App über HTTP anstelle der echten API aufruft. Es testet Ihren HTTP-Client, aber Sie müssen Ihre App so konfigurieren, dass sie seine URL verwendet.
• Emulator: eine lokale Version eines Diensts, die in der Regel vom Besitzer des Diensts veröffentlicht wird und sich für die unterstützten Vorgänge wie die echte verhält. Überprüfen Sie, welche Einschränkungen und Fehler sie abdeckt, bevor Sie sie für die Fehlerbehandlung verwenden.
• Interceptierender Proxy: Er befindet sich im Netzwerk zwischen Ihrer App und der API. Ihre App ruft die echte URL auf, und der Proxy leitet Anfragen weiter oder beantwortet einige davon mit der von Ihnen definierten Antwort. Ihre App muss den Datenverkehr über den Proxy senden und für HTTPS dem Proxyzertifikat vertrauen.

So testen Sie Code, der eine API aufruft

Sie benötigen mehr als 1 davon. Stubs halten Ihre Unit-Tests schnell. Ein Proxy zeigt Ihnen, was die gesamte App tut, wenn die echte API sich fehlerhaft verhält. Weitere Informationen dazu, wie die 2 zusammenpassen, finden Sie unter Dev Proxy vs Unit Tests.

Was Coding-Agenten erstellen

Wenn Sie einen Coding-Agent bitten, Ihre App mit API-Fehlern umgehen zu lassen und zu zeigen, dass das funktioniert, wählt er einen Stand-in für Sie aus. Wir wollten wissen, welcher davon, also haben wir einen Test mit 3 Coding-Agenten durchgeführt (210 Läufe). Die aufgaben verwendeten ausdrücke wie "handle rate limiting properly and show me that it works", "verify it without spending money on real API calls", and "run this without an OpenAI key or an internet connection".

• In 76% der 140-Ausführung, die nach Arbeitscode gefragt wurde, hat der Agent den Fehler manuell erstellt: Stubs abrufen, httpx.MockTransportoder einen Throwaway-HTTP-Server.
• In 61 von 105 Durchläufen in Apps, die GitHub, OpenAI oder eine Wetter-API aufrufen, hat der Agent der App eine Basis-URL oder einen Konfigurationsschalter hinzugefügt, damit sie ihr Fake-Ziel erreichen konnte.
• In den 75 Durchläufen, in denen die echte API verfügbar war und die Eingabeaufforderung sie nicht ausgeschlossen hat, wurde die App in 0 Fällen auf ihrer echten API-URL getestet.

Stubs sind eine vernünftige Wahl für Unit-Tests. Die Lücke ist das, was sie weglassen. Der Stub des Agents gibt den Fehler zurück, den der Agent erwartet hat, was möglicherweise nicht mit dem übereinstimmt, was die API sendet. Und der Schalter, der hinzugefügt wurde, um über Ihre App auf die gefälschten Schiffe zuzugreifen.

So arbeiten Sie mit den Tests Ihres Agents

• Halten Sie die Stubs für Ihre Logik. Sie sind schnell und testen die Branches, die der Agent geschrieben hat.
• Fragen Sie nach dem tatsächlichen Fehlerformat. Bitten Sie den Agenten, jeden simulierten Fehler auf die dokumentierten Statuscodes, Kopfzeilen und Body-Felder des Anbieters zu stützen. Eine bloße 429 testet nicht, ob Ihre App retry-after liest oder einen Abrechnungsfehler von einer Ratenbegrenzung unterscheidet.
• Prüfschalter, die für Tests hinzugefügt wurden. Wenn der Agent nur eine Basis-URL-Einstellung hinzufügt, damit Tests einen Mock erreichen können, entscheiden Sie, ob Sie diese Einstellung in Ihrem Produktionscode haben möchten.
• Führen Sie die App einmal auf echten URLs mit simulierten Fehlern aus. Bevor Sie die App veröffentlichen, überprüfen Sie, was die ausgeführte App, das zugehörige SDK und ihre Wiederholungsrichtlinie mit den Fehlern der API selbst tun. Informationen zum schrittweisen Überprüfen der Fehlerbehandlung des Agents finden Sie unter So überprüfen Sie die Fehlerbehandlung, die Ihr Coding-Agent geschrieben hat.

Probieren Sie sie mit Ihrer App aus

Dev Proxy ist ein abfangender Proxy für die Entwicklung. Sie gibt die Antworten für die URLs zurück, die Ihre App bereits aufruft, ohne dass Änderungen am App-Code erforderlich sind. Aktivieren Sie MockResponsePlugin in Ihrer Konfiguration, 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"
  }
}

Definieren Sie dann die Antwort in mocks.json. Diese gibt Retry-After mit einem 503 Header für den Prognoseendpunkt zurück:

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

Starten Sie Dev Proxy, und führen Sie Ihre App wie gewohnt aus:

devproxy --config-file devproxyrc.json

Anfragen, die nicht mit einem Mock übereinstimmen, gehen zur echten API. Wenn Sie ein Back-End benötigen, das noch nicht vorhanden ist, simuliert CrudApiPlugin eine CRUD-API mit im Arbeitsspeicher gespeicherten Daten. Wenn Sie einen Teil der Anfragen zufällig statt jedes Mal fehlschlagen lassen möchten, lesen Sie „Meine App mit zufälligen Fehlern testen“. Informationen zum Installieren von Dev Proxy finden Sie unter Einrichten von Dev Proxy.

Nächste Schritte

Siehe auch

• Dev Proxy vs Unit Tests
• Was ist ein Proxy?
• Simulieren einer CRUD-API
• So überprüfen Sie die Fehlerbehandlung, die Ihr Coding-Agent erstellt hat