Was ist API-Mocking? Tools, Anwendungsfälle, Beispiele

Was ist API-Mocking?

Beim API-Mocking ersetzt man eine echte API durch eine Attrappe, die vorab definierte Antworten liefert. Der Client ruft dieselben URLs auf und bekommt dasselbe Antwortformat, aber nichts erreicht das echte Backend: keine Datenbank, keine Nebenwirkungen, keine Rechnung eines Drittanbieters. Weil Sie die Antworten bestimmen, werden Tests deterministisch, und Sie können Fälle auslösen, die sich sonst schwer erzeugen lassen, etwa einen 500-Fehler oder eine langsame Antwort.

Mocks dienen vor allem dazu, ein Frontend vor dem Backend zu entwickeln, automatisierte Tests von möglicherweise ausgefallenen Diensten unabhängig zu halten und zu prüfen, ob ein Client die dokumentierten Antworten richtig verarbeitet. Ein Mock ist ein Werkzeug für Entwicklung und Tests, kein Ersatz für Tests gegen die echte API. Mehr dazu unter API-Tests.

So funktioniert API-Mocking

Ein Mock-Server (oder ein Interceptor im Testprozess) nimmt eine Anfrage entgegen, erkennt sie an Methode, Pfad, Headern oder Body und antwortet mit einer festen oder berechneten Antwort. Den Client lenken Sie per geänderter Basis-URL auf den Mock, meist über eine Umgebungsvariable. Ein Interceptor fängt ausgehende Aufrufe dagegen ab, sodass der Code unverändert bleibt.

// Dev: API_BASE=http://localhost:8000 (Mock)
// Prod: API_BASE=https://api.example.com (echt)
const API_BASE = process.env.API_BASE || 'https://api.example.com';
fetch(`${API_BASE}/users/42`);

Wann API-Mocking sinnvoll ist

• Frontend-Arbeit vor dem fertigen Backend. Gegen das vereinbarte JSON-Format entwickeln, später die Basis-URL tauschen.
• Unit- und Integrationstests. Kein Netzwerk, kein unzuverlässiger Drittanbieter.
• Fehlerfälle. 429, 500 oder ein Timeout, wann immer Sie ihn brauchen.
• Kostenpflichtige oder limitierte APIs. Weder zahlen noch gedrosselt werden bei jedem Testlauf.
• Demos und Offline-Arbeit. Keine Produktionsdaten, keine Verbindung nötig.

Arten von API-Mocks

• Statisch: immer dieselbe Antwort.
• Dynamisch: die Antwort hängt von Pfad, Query-String oder Body ab.
• Aufgezeichnet: echte Antworten einmal mitgeschnitten und später abgespielt.
• Spezifikationsbasiert: aus einer OpenAPI-Datei erzeugt, sodass der Mock dem dokumentierten Schema folgt (siehe Swagger).
• Zustandsbehaftet: ein POST legt etwas an, das ein späteres GET zurückgibt. Nützlich für Ende-zu-Ende-Abläufe, aber aufwendig zu pflegen.

Gängige Tools für API-Mocking

Beispiel mit MSW (Syntax ab v2):

import { setupServer } from 'msw/node';
import { http, HttpResponse } from 'msw';

const server = setupServer(
  http.get('https://api.example.com/users/:id', ({ params }) => {
    return HttpResponse.json({ id: params.id, name: 'Alice' });
  })
);
beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

Beispiel mit nock:

const nock = require('nock');
nock('https://api.example.com')
  .get('/users/42')
  .reply(200, { id: 42, name: 'Alice' });

Mock, Stub, Fake und Spy

• Stub: liefert eine feste Antwort.
• Mock: ein Stub, der zusätzlich prüft, ob er wie erwartet aufgerufen wurde.
• Fake: eine funktionierende, vereinfachte Implementierung, etwa eine In-Memory-Datenbank.
• Spy: umhüllt den echten Aufruf und protokolliert, was gesendet wurde.

Im Alltag steht "Mocking" für alle vier. Die genauen Unterschiede zählen nur in Unit-Test-Frameworks.

Häufige Fehler

• Der Mock weicht von der echten API ab. Der Anbieter ändert ein Feld, der Mock nicht, die Tests bleiben grün und die Produktion bricht. Erzeugen Sie Mocks aus der Spezifikation oder nutzen Sie Contract-Testing, das beide Seiten gegen denselben Vertrag prüft.
• Nur gegen Mocks testen. Behalten Sie einige Integrationstests gegen eine Staging- oder echte API.
• Zu nachsichtige Mocks. Die echte API validiert Eingaben und lehnt ab, was der Mock akzeptiert.
• Nur der Idealfall. Ergänzen Sie Fehler, leere Ergebnisse, langsame Antworten und fehlerhafte Bodys. Mehr in häufige Mocking-Fehler beim API-Testing (englisch).
• Ein Mock, der zum zweiten Backend wächst. Braucht er eigene Geschäftslogik, nehmen Sie lieber eine Testumgebung.

Mocks, Lasttests und Monitoring

Ein Lasttest gegen einen Mock misst den Mock, nicht Ihren Dienst. Belegen Sie damit also nicht, dass Ihre API Last aushält. Innerhalb eines Lasttests helfen Mocks, wenn hinter Ihrem Dienst ein langsamer oder limitierter Drittanbieter steht: Ersetzen Sie diese Abhängigkeit, damit das Ergebnis Ihren eigenen Code zeigt. Den eigentlichen Kapazitätstest führen Sie gegen die echte API in einer Staging-Umgebung durch, etwa mit dem Lasttest von LoadFocus (JMeter- und k6-Skripte).

Ob sich die echte API nach dem Release ändert, sagt Ihnen ein Mock nicht. Das leisten geplante Prüfungen gegen den Live-Endpunkt: LoadFocus API-Monitoring ruft Ihre Endpunkte planmäßig auf (im kostenlosen Tarif alle 5 Minuten), prüft Statuscode, Antwortzeit und Body und alarmiert bei Fehlern. Verwandt: API-Monitoring, API-Endpunkt, Regressionstest.

Häufige Fragen zu API-Mocking

Was unterscheidet Mocking von einer Staging-API?

Ein Mock ist lokal, schnell und vollständig unter Ihrer Kontrolle. Eine Staging-API ist ein echtes Deployment des Dienstes ohne Produktionsdaten. Mocks eignen sich für Unit-Tests und Entwicklung, Staging für Integrations- und Ende-zu-Ende-Tests.

Sollte ich jede externe API in Tests mocken?

In Unit-Tests ja, damit Ihr Code isoliert getestet wird. In Integrationstests sollten Sie mindestens einige Aufrufe gegen einen echten oder Staging-Dienst behalten, um Probleme zu finden, die ein Mock nicht zeigt.

Wie mocke ich dynamische Antworten?

Die meisten Tools berechnen eine Antwort aus der Anfrage: WireMock bietet Response-Templating, Mockoon unterstützt dynamische Daten, und MSW-Handler sind normale JavaScript-Funktionen.

Kann ich GraphQL oder gRPC mocken?

GraphQL ja, MSW unterstützt es. Für gRPC brauchen Sie ein gRPC-spezifisches Mock-Tool, da reine HTTP-Mocks das Protokoll nicht sprechen.

Wie halte ich einen Mock aktuell?

Erzeugen Sie ihn nach Möglichkeit aus der OpenAPI-Spezifikation und ergänzen Sie Contract-Tests oder eine geplante Prüfung gegen den echten Endpunkt, damit eine Änderung beim Anbieter einen Test scheitern lässt statt die Produktion.