Tests, die von einer Live-API abhängen, sind Tests, die aus den falschen Gründen fehlschlagen. Ein Staging-Server geht offline, eine Ratenbegrenzung eines Drittanbieters greift, ein Teamkollege ändert einen Datensatz, und plötzlich ist Ihre Suite rot, obwohl Ihr Code in Ordnung ist. Das Mocken der API beseitigt diese Zerbrechlichkeit. Sie ersetzen den echten Endpunkt durch einen kontrollierten Platzhalter, der jedes Mal genau die gewünschte Antwort zurückgibt.
Dieser Leitfaden führt Sie durch die tatsächlichen Schritte zum Mocken einer API für Tests. Sie definieren ein Schema, generieren Mock-Antworten, richten Ihren Testcode auf den Mock aus und decken die Fehlerpfade ab, die ein realer Server selten auf Abruf produziert. Die Beispiele verwenden eine kleine Auftragsverwaltungs-API, aber der Workflow gilt für jeden REST- oder GraphQL-Dienst.
Wann das Mocken der API die richtige Entscheidung ist
Mocken Sie die API, wenn das, was Sie testen möchten, Ihr eigener Code ist, nicht das Netzwerk. Unit-Tests und die meisten Integrationstests fallen in diese Kategorie. Sie möchten wissen, dass Ihr Client einen 200-Status korrekt parst, bei einem 503 erneut versucht und bei einem 404 eine klare Meldung ausgibt. Nichts davon erfordert einen echten Server.
Behalten Sie die echte API für Vertragstests und eine dünne Schicht von End-to-End-Prüfungen. Diese dienen dazu, zu bestätigen, dass der Mock immer noch der Realität entspricht. Wenn Sie alles mocken und niemals gegen den Live-Dienst überprüfen, bleibt Ihre Suite grün, während die Produktion ausfällt. Die Aufteilung ist grob: Mocken für Geschwindigkeit und Isolation, das reale System verwenden, um den Vertrag zu bestätigen. Für einen tieferen Einblick, wo jeder Ansatz passt, sehen Sie sich diese Aufschlüsselung der Szenarien an, in denen sich API-Mocking auszahlt, und die Unterscheidung zwischen einem Mock-Server und einem realen Server.
Der Fünf-Schritte-Workflow auf einen Blick
Das Mocken einer API für Tests besteht jedes Mal aus denselben fünf Schritten, unabhängig von Sprache oder Framework:
- Definieren Sie das Schema, damit der Mock die tatsächliche Antwortform widerspiegelt.
- Generieren Sie Mock-Antworten, statisch oder dynamisch, aus diesem Schema.
- Starten Sie einen Mock-Server, der diese Antworten unter einer URL bereitstellt.
- Richten Sie Ihre Tests auf den Mock aus, indem Sie die Basis-URL konfigurierbar machen.
- Testen Sie die Fehlerpfade, die der reale Server nicht auf Abruf produzieren wird.
Der Rest dieses Leitfadens behandelt jeden Schritt mit einem konkreten Beispiel: eine kleine Auftragsverwaltungs-API mit einem GET /orders/{id}-Endpunkt. Behalten Sie diesen Endpunkt als roten Faden im Hinterkopf.
Schritt 1: Das Schema definieren
Ein Mock ist nur nützlich, wenn er die tatsächliche Antwortform widerspiegelt. Beginnen Sie mit einem Schema. Wenn Ihre API bereits ein OpenAPI-Dokument hat, verwenden Sie es. Falls nicht, schreiben Sie eines für den zu testenden Endpunkt. Hier ist eine gekürzte Definition für GET /orders/{id}:
paths:
/orders/{id}:
get:
parameters:
- name: id
in: path
required: true
schema: { type: string }
responses:
'200':
content:
application/json:
schema:
type: object
properties:
id: { type: string }
status: { type: string, enum: [pending, shipped, delivered] }
total: { type: number }
items: { type: array, items: { type: object } }
'404':
description: Order not found
Das Schema erfüllt zwei Aufgaben. Es sagt dem Mock, welche Felder zurückgegeben werden sollen, und es bietet Ihnen eine einzige Quelle der Wahrheit. Wenn das Backend den Vertrag ändert, aktualisieren Sie das Schema und jeder daraus abgeleitete Mock bleibt korrekt. Schema-basiertes Mocking ist das, was API-Vertragstests ehrlich hält.
Schritt 2: Mock-Antworten generieren
Sie haben zwei Möglichkeiten, den Antwort-Body zu erzeugen.
Statische Antworten sind festes JSON. Sie schreiben die genaue Payload einmal und der Mock gibt sie unverändert zurück. Sie sind vorhersehbar und leicht zu überprüfen, was sie ideal für Unit-Tests macht, bei denen Sie einen bekannten Wert benötigen.
Dynamische Antworten werden pro Anfrage generiert. Anstatt "total": 149.99 fest zu codieren, füllt der Mock Felder mit realistischen generierten Werten: eine UUID für id, ein zufälliges Enum-Mitglied für status, einen plausiblen Währungsbetrag für total. Dynamische Daten fangen Fehler ab, die eine einzelne feste Payload verbergen würde, wie einen Parser, der bei langen Zeichenketten oder unerwarteten Null-Feldern abstürzt.
Die meisten Teams verwenden beides. Statische Payloads für assertionsintensive Tests, dynamische Generierung für Fuzzing-ähnliche Abdeckung. Mit Apidog schreiben Sie beides nicht von Hand. Apidog liest das Schema und generiert automatisch einen Mock-Endpunkt, der Feldnamen wie email, phone oder avatar dem korrekten Datentyp zuordnet. Sie rufen die Mock-URL in einem Browser auf und erhalten sofort eine gültige Antwort.
Wenn Sie Payloads von Hand schreiben, halten Sie sie realistisch. Eine Testbestellung mit "total": 0 und einem leeren items-Array besteht einen naiven Parser, verbirgt aber Fehler. Verwenden Sie Werte, die der Produktion ähneln: eine real aussehende Gesamtsumme, zwei oder drei Positionen, ein Status, der tatsächlich im Enum enthalten ist. Je näher die Mock-Daten an dem sind, was eine reale Anfrage zurückgibt, desto wertvoller ist Ihr Test.
Schritt 3: Den Mock-Server starten
Eine Mock-Antwort ist nutzlos, solange nichts sie bereitstellt. Sie haben zwei Hosting-Möglichkeiten.
Ein lokaler Mock-Server läuft auf Ihrem Rechner, normalerweise auf einem Port wie localhost:4010. Er ist schnell, funktioniert offline und ist die Standardeinstellung für Unit- und Integrationstests. Leichte Tools wie Prism starten einen direkt aus einer OpenAPI-Datei:
prism mock openapi.yaml
# Mock server listening on http://127.0.0.1:4010
Ein Cloud-Mock-Server hat eine öffentliche URL. Greifen Sie darauf zurück, wenn eine mobile App, ein CI-Runner oder ein externer Mitarbeiter den Mock aufrufen muss, ohne Zugang zu Ihrem Laptop zu haben. Apidog bietet jedem Projekt eine gehostete Cloud-Mock-URL, sodass ein Teamkollege in einem anderen Netzwerk denselben Endpunkt erreichen kann wie Sie.
Für Testläufe bevorzugen Sie lokal. Es gibt keine Netzwerklatenz und keinen gemeinsamen Zustand, sodass zwei Builds niemals kollidieren. Verwenden Sie die Cloud-Option für Demos und Cross-Device-Tests.
Schritt 4: Ihre Tests auf den Mock ausrichten
Verbinden Sie nun den Testcode mit dem Mock anstatt mit der Produktion. Der sauberste Ansatz ist eine konfigurierbare Basis-URL. Lesen Sie diese aus einer Umgebungsvariablen, damit dieselbe Testdatei lokal gegen den Mock und in einem Vertragsjob gegen die echte API ausgeführt wird.
// orderClient.test.js
import { getOrder } from './orderClient.js';
const BASE_URL = process.env.API_BASE_URL || 'http://127.0.0.1:4010';
test('parses a shipped order', async () => {
const order = await getOrder('order_8842', BASE_URL);
expect(order.status).toBe('shipped');
expect(typeof order.total).toBe('number');
});
Der Client übernimmt die Basis-URL als Argument; nichts im Produktionscode weiß, dass er gemockt wird. In CI setzen Sie API_BASE_URL vor dem Ausführen der Suite auf die Adresse des Mocks. Dieses Muster hält das Mocking vollständig aus Ihrer Anwendungslogik heraus, wo es hingehört. Wenn Sie Tests über eine Pipeline ausführen, gilt dieselbe Idee, wenn Sie API-Tests in CI/CD automatisieren.
Schritt 5: Die Fehlerpfade testen
Dies ist der Schritt, den die meisten Teams überspringen, und es ist derjenige, der sich am meisten auszahlt. Ein echter Server gibt selten einen 500-Fehler zurück, wenn Sie es wollen. Ein Mock gibt einen auf Befehl zurück.
Konfigurieren Sie den Mock so, dass er spezifische Fehlerantworten liefert, und überprüfen Sie dann, ob Ihr Client jede davon handhabt:
| Szenario | Mock gibt zurück | Was Sie erwarten |
|---|---|---|
| Fehlender Datensatz | 404 |
Client wirft einen klaren „nicht gefunden“-Fehler |
| Serverfehler | 500 |
Client versucht es erneut, zeigt dann einen Fallback an |
| Ratenbegrenzt | 429 mit Retry-After |
Client verlangsamt korrekt |
| Langsame Antwort | 200 nach 5s Verzögerung |
Client bricht ab und erholt sich |
| Fehlerhafter Body | 200 mit fehlerhaftem JSON |
Client schlägt sauber fehl, kein Absturz |
Apidogs erweiterte Mock-Regeln ermöglichen es Ihnen, unterschiedliche Antworten basierend auf der Anfrage zurückzugeben, sodass eine Anfrage für order_404 einen 404-Fehler liefert, während jede andere ID eine normale 200-Antwort zurückgibt. Das gibt Ihnen einen Mock-Endpunkt, der sowohl den Erfolgsfall als auch die Fehler abdeckt. Kombinieren Sie dies mit starken API-Assertions, und Ihre Suite überprüft das Verhalten, nicht nur die Statuscodes.
Mocks in einer wachsenden Test-Suite organisieren
Ein einzelner Mock-Endpunkt ist einfach. Hundert davon, über eine Suite verteilt, ist der Punkt, an dem Teams die Kontrolle verlieren. Ein paar Gewohnheiten halten das Ganze überschaubar.
Gruppieren Sie Mocks nach dem realen Dienst, für den sie stehen, nicht nach dem Test, der sie verwendet. Wenn sich die Zahlungs-API ändert, möchten Sie eine zentrale Stelle zum Aktualisieren haben, nicht zwanzig Testdateien. Benennen Sie Mock-Fixtures nach dem Szenario, das sie repräsentieren, wie order-shipped oder order-rate-limited, damit ein fehlschlagender Test klar lesbar ist. Halten Sie die Mock-Definitionen in der Versionskontrolle neben den Tests, da ein Mock Teil des Tests ist und die gleiche Überprüfung verdient.
Widerstehen Sie dem Drang, jedem Test seine eigene, maßgeschneiderte Payload zu geben. Die meisten Tests wünschen dasselbe realistische Bestellobjekt mit einem geänderten Feld. Definieren Sie eine Basisantwort einmal und überschreiben Sie nur das zu testende Feld. Das hält die Suite lesbar und bedeutet, dass eine Vertragsänderung eine Basisdefinition betrifft, anstatt verstreute Kopien. Dieselbe Disziplin, die eine Test-Suite für die API-Automatisierung wartbar macht, gilt direkt für die dahinter stehenden Mocks.
Den Mock ehrlich halten
Ein Mock driftet ab. Das Backend fügt ein Feld hinzu, benennt total in amount um oder ändert ein Enum, und Ihr Mock gibt weiterhin die alte Form zurück. Tests bestehen; die Produktion schlägt fehl. Dies ist die häufigste Art, wie Mocking schiefgeht, und es ist still. Nichts in Ihrer Suite beschwert sich, weil die Suite den Mock an sich selbst misst.
Zwei Gewohnheiten verhindern dies. Erstens, leiten Sie den Mock vom selben Schema ab, das das Backend veröffentlicht, sodass eine Vertragsänderung beide gleichzeitig aktualisiert. Ein aus einer OpenAPI-Datei generierter Mock wird neu generiert, wenn diese Datei geändert wird; ein von Hand eingegebener Mock nicht. Zweitens, führen Sie eine kleine Reihe von Vertragstests gegen die reale API nach einem Zeitplan aus. Ihre einzige Aufgabe ist es, zu bestätigen, dass die Live-Antwort immer noch dem Schema entspricht, das Ihre Mocks verwenden. Wenn sie fehlschlagen, wissen Sie, dass der Mock veraltet ist, bevor es die Benutzer tun.
Es hilft auch, Mocks während der Code-Überprüfung zu überprüfen. Wenn ein Pull Request eine API-Antwort ändert, sollte der Prüfer überprüfen, ob sich der entsprechende Mock ebenfalls geändert hat. Die Behandlung des Mocks als Teil des Vertrags und nicht als wegwerfbares Testhilfsmittel ist das, was eine gemockte Suite über Monate von Änderungen hinweg vertrauenswürdig hält.
Wenn Sie eine einzige Umgebung wünschen, die das Schema enthält, den Mock generiert und die Tests dagegen ausführt, laden Sie Apidog herunter. Es hält Design, Mock-Server und Test-Suite synchron, sodass der Mock, gegen den Sie testen, immer dem aktuellen Vertrag entspricht. Für umfassendere Optionen vergleichen Sie das Feld in dieser Übersicht der REST-API-Mocking-Tools.
Häufig gestellte Fragen
Sollte ich die API für jeden Test mocken?
Nein. Mocken Sie für Unit- und Integrationstests, bei denen Sie Ihren eigenen Code überprüfen. Halten Sie eine kleine Reihe von Vertrags- und End-to-End-Tests, die die echte API aufrufen, da diese bestätigen, dass Ihr Mock immer noch der Produktion entspricht. Alles zu mocken verbirgt eine Vertragsdrift.
Was ist der Unterschied zwischen einer statischen und einer dynamischen Mock-Antwort?
Eine statische Antwort ist eine feste JSON-Payload, die sich nie ändert, was gut für vorhersehbare Assertions ist. Eine dynamische Antwort wird pro Anfrage mit realistischen Werten generiert, was Fehler abfängt, die eine einzelne feste Payload übersehen würde. Die meisten Teams verwenden beides.
Wie stelle ich sicher, dass mein Mock genau bleibt?
Generieren Sie den Mock aus demselben Schema, das das Backend verwendet, idealerweise einem OpenAPI-Dokument. Führen Sie dann geplante Vertragstests gegen die reale API aus, um zu bestätigen, dass die Live-Antwort immer noch diesem Schema entspricht. Wenn sie fehlschlagen, muss Ihr Mock aktualisiert werden.
Kann ein Mock langsame oder fehlerhafte Antworten simulieren?
Ja, und das ist einer der stärksten Gründe für das Mocking. Sie können einen Mock so konfigurieren, dass er einen 500-Fehler, einen 429-Fehler mit einem Retry-After-Header oder eine verzögerte 200-Antwort zurückgibt. So können Sie die Retry-Logik und Timeouts überprüfen, die ein gesunder realer Server niemals auf Abruf auslösen würde.
Lokaler Mock-Server oder Cloud-Mock-Server für Tests?
Verwenden Sie einen lokalen Mock-Server für Testläufe. Er ist schnell, hat keine Netzwerklatenz und vermeidet gemeinsamen Zustand zwischen Builds. Verwenden Sie einen Cloud-gehosteten Mock, wenn ein mobiles Gerät, ein CI-Runner oder ein externer Mitarbeiter den Mock erreichen muss, ohne Zugriff auf Ihren Computer zu haben.