Mock-Server für die lokale Entwicklung: Platzhalter-Abhängigkeiten, die wie das Original antworten

Worum es geht

Ein Mock-Server ist ein Prozess, oder im Browser ein Service Worker, der HTTP-Anfragen anstelle einer Abhängigkeit beantwortet, die lokal nicht laufen soll: ein Zahlungsanbieter, ein Identitätsdienst, die unfertige API eines Teammitglieds. Die Stubbing-Dokumentation von WireMock zeigt die Form: Ein Stub gleicht eine Anfrage ab (get(urlEqualTo("/some/thing"))) und liefert einen konfigurierten Status, Header und Body zurück; Stubs können im Code oder als JSON-Dateien deklariert werden. Mock Service Worker beschreibt die browserseitige Variante: Sie nutzt die Service-Worker-API, um tatsächliche Produktionsanfragen auf Netzwerkebene abzufangen, sodass der Anwendungscode fetch unverändert weiter aufruft. Das unterscheidet sich von Testdoubles innerhalb des Codes, die eine Funktion statt eines Netzwerk-Endpunkts ersetzen, und von Contract-Tests, die eine Integration überprüfen. Ein Mock-Server existiert, damit Entwicklung, Demos und Frontend-Arbeit ohne die Abhängigkeit fortschreiten können.

Warum es wichtig ist

Auf eine Abhängigkeit zu warten, sich einen Staging-Mandanten zu teilen oder eine kostenpflichtige API von jeder Entwicklungsmaschine aus aufzurufen, verlangsamt die Arbeit und macht lokale Läufe instabil. Ein Mock macht das Verhalten der Abhängigkeit explizit und wiederholbar, einschliesslich der Fehlerpfade (Timeouts, 429er, fehlerhafte Bodies), die das echte System auf Abruf selten produziert.

So wird es angewendet

• Die Basis-Stubs aus dem OpenAPI-Dokument der Abhängigkeit oder aus aufgezeichnetem Verkehr generieren und danach bearbeiten; von Hand geschriebene Stubs driften am schnellsten auseinander.
• Stubs im Repository neben dem Code halten, der sie verwendet, eine Datei pro Szenario (happy-path, card-declined, upstream-timeout), und das Szenario über einen Header oder ein Query-Flag auswählen statt durch einen Neustart des Servers.
• Latenz- und Fehler-Stubs einbeziehen und den Retry- und Timeout-Code der Client-Seite lokal dagegen testen.
• Denselben Mock in der CI für das Frontend oder die Integrationsschicht laufen lassen, damit ein grüner Build nicht davon abhängt, dass ein Drittanbieter erreichbar ist.
• In regelmässigen Abständen neu aufzeichnen oder neu generieren und gegen die vorherigen Stubs diffen; der Diff ist eine Frühwarnung, dass sich die Abhängigkeit geändert hat.

Stolpersteine

Ein Mock, der immer mit 200 antwortet, trainiert den Code darauf, das zu erwarten. Aus Produktionsantworten kopierte Stubs können Personendaten enthalten; vor dem Commit bereinigen. Ein zu lockerer Abgleich verbirgt Routing-Fehler; ein zu strenger Abgleich (vollständige Body-Gleichheit) bricht bei harmlosen Änderungen. Ein Mock ist kein Beleg dafür, dass die Integration funktioniert; das sind Contract-Tests und ein Lauf gegen die echte Sandbox.