Wenn Sie Frontend-Tests schreiben, sind Sie wahrscheinlich schon auf Mock Service Worker (MSW) gestoßen. Es ist die bevorzugte Bibliothek zum Abfangen von Anfragen innerhalb des Browsers und von Node, und für Unit- und Komponententests ist sie kaum zu schlagen. Dieser Leitfaden erklärt, was MSW gut macht, wo es an seine Grenzen stößt und wann eine gehostete API-Mocking-Plattform sinnvoller ist.
Was ist Mock Service Worker?
Mock Service Worker ist eine JavaScript-Bibliothek, die Netzwerkanfragen an der Quelle abfängt. Im Browser registriert sie einen Service Worker, der ausgehende fetch- und XMLHttpRequest-Aufrufe abfängt. In Node patcht sie die Request-Schicht, sodass dieselben Handler in Jest oder Vitest laufen. Sie schreiben Request-Handler, die einer Methode und einem Pfad entsprechen, und geben dann die gewünschte Antwort zurück.
Das Design ist clever. Ihr Anwendungscode ruft weiterhin die echten Netzwerk-APIs auf. MSW sitzt dazwischen und antwortet, sodass Sie fetch nicht stubben oder Ihren HTTP-Client austauschen müssen. Dieselbe Mock-Definition funktioniert in Tests und in einem laufenden Entwicklungs-Build, weshalb so viele React- und Vue-Teams darauf zurückgreifen. Sie können den MSW-Quellcode auf GitHub einsehen, um zu verstehen, wie die Interception-Schicht funktioniert.
Ein typischer Handler sieht so aus:
import { http, HttpResponse } from 'msw'
export const handlers = [
http.get('/api/users/:id', ({ params }) => {
return HttpResponse.json({ id: params.id, name: 'Ada Lovelace' })
}),
]
Das ist der ganze Reiz. Der Mock lebt neben Ihrem Code, er ist versionskontrolliert mit Ihren Tests und läuft überall dort, wo Ihr JavaScript ausgeführt wird.
Wo MSW glänzt
MSW ist eine gute Wahl, wenn der Mock und der Konsument in derselben Codebasis leben. Einige Fälle, in denen es wirklich das richtige Tool ist:
- Komponenten- und Unit-Tests. Rendern Sie eine Komponente, lassen Sie sie ihre echten Anfragen abfeuern und geben Sie vordefinierte Daten zurück. Keine Test-Doubles zum Einrichten. Wenn Sie es mit dem direkten Spionieren auf den Client vergleichen, sehen Sie, wie sich dies von einem Jest-Mock eines API-Aufrufs unterscheidet.
- Lokale Frontend-Entwicklung. Erstellen Sie die Benutzeroberfläche, bevor das Backend existiert. Schalten Sie Handler um, um Ladezustände, Fehler oder leere Zustände bei Bedarf zu simulieren.
- Deterministische CI. Tests greifen nicht auf einen Live-Server zu, sodass sie bei Netzwerkbedingungen oder gemeinsam genutzten Staging-Daten nicht instabil werden.
- Eine Sprache, ein Team. Wenn die Leute, die den Mock schreiben, auch diejenigen sind, die ihn konsumieren, ist es der einfachste Weg, die Handler im Repo zu behalten.
Wenn dies Ihre Situation beschreibt, brauchen Sie wahrscheinlich nichts anderes. MSW ist kostenlos, Open Source und genau dafür gebaut.
Wo MSW an seine Grenzen stößt
Dasselbe, was MSW in einem einzelnen Repo so großartig macht – Mocks, die als Code in diesem Repo leben – begrenzt es, sobald mehr Leute involviert sind. Hier neigen Teams dazu, darüber hinauszuwachsen.
Nicht-JavaScript-Konsumenten
MSW-Handler sind JavaScript. Wenn Ihr Mobilteam in Swift oder Kotlin schreibt oder Ihre Backend-Integrationstests in Go oder Python laufen, können sie Ihre Handler nicht importieren. Sie bräuchten ihre eigenen Mocks, die von Ihren abweichen würden. Ein sprachunabhängiger Mock-Server, der HTTP über eine echte URL spricht, funktioniert für jeden Client, unabhängig von der Sprache.
Geteilte, ständig verfügbare Mocks
MSW läuft innerhalb eines Prozesses. Es gibt keine gemeinsame URL, die ein QA-Ingenieur, ein Designer oder ein Partnerteam von ihrem eigenen Rechner aus aufrufen kann. In dem Moment, in dem Sie einen Endpunkt wünschen, den mehrere Personen gleichzeitig nutzen, benötigen Sie einen gehosteten Mock-Server mit einer stabilen Adresse, keinen Service Worker, der an einen Browser-Tab gebunden ist.
Design-First- und schema-gesteuerte Workflows
Wenn Sie APIs in OpenAPI entwerfen, bevor Sie Code schreiben, möchten Sie, dass Mocks automatisch aus der Spezifikation generiert werden, sodass der Mock nicht vom Vertrag abweichen kann. MSW erwartet, dass Sie Handler manuell schreiben. Mocks direkt aus einem Schema zu generieren, ist ein anderes Modell. Mehr zu diesem Ansatz finden Sie in diesem Leitfaden zum API-Mocking und den dazugehörigen Mustern.
Realistische, dynamische Daten in großem Maßstab
MSW gibt zurück, was Ihr Handler codiert. Für lebensechte Daten über viele Felder hinweg schreiben Sie diese Logik selbst. Plattformen, die Faker-ähnliche Generierung und Feldnamen-Inferenz integrieren, liefern Ihnen realistische Antworten, ohne dass Sie jede einzeln von Hand erstellen müssen.
MSW vs. eine vollständige API-Mocking-Plattform
Hier ist ein ehrlicher Vergleich. Keine Spalte ist im abstrakten Sinne „besser“; sie lösen unterschiedliche Probleme.
| Fähigkeit | Mock Service Worker | Gehostete API-Plattform (z.B. Apidog) |
|---|---|---|
| Läuft in JS Unit-/Komponententests | Ja, nativ | Nein, es ist keine JS-Testbibliothek |
| Sprachunabhängig über HTTP | Nein (nur JS) | Ja, jeder Client |
| Geteilte URL für das ganze Team | Nein | Ja, gehosteter Mock-Server |
| Mocks aus OpenAPI generieren | Manuell | Automatisch aus Schema |
| Intelligente/dynamische Datengenerierung | Manuell codiert | Integriert |
| Lebt in Ihrem Repo mit Tests | Ja | In einem gemeinsamen Projekt gespeichert |
| Kosten | Kostenlos, Open Source | Kostenloser Tarif + kostenpflichtige Pläne |
Das Fazit: MSW ist die richtige Wahl für Frontend-Tests und lokale Entwicklung. Eine Plattform wie Apidog ist die richtige Wahl, wenn der Mock geteilt, sprachneutral oder durch eine Spezifikation angetrieben werden muss.
Apidog als Ergänzung, nicht als Ersatz
Um es klarzustellen: Apidog ist kein direkter Ersatz für MSW innerhalb von Jest oder Vitest. Es ist keine JavaScript-Bibliothek, die Sie in eine Testdatei importieren. Betrachten Sie es als die Schicht oberhalb Ihrer Unit-Tests, den Ort, an dem Mocks zu einer gemeinsam genutzten, sprachunabhängigen Ressource für das gesamte Team werden.
So sieht das in der Praxis aus. Sie entwerfen oder importieren eine API in Apidog, und es generiert automatisch einen Mock-Endpunkt aus dem Schema. Der Mock erhält eine echte URL, die Ihre Frontend-, Mobil- und QA-Teammitglieder alle aufrufen können. Apidog füllt Antworten mit realistischen Daten, indem es aus Feldnamen ableitet, sodass ein Feld namens email eine E-Mail und createdAt ein Datum zurückgibt. Sie können auch benutzerdefinierte Regeln schreiben, wenn Sie eine spezifische 500er-Antwort oder einen bestimmten Edge Case benötigen.
Da der Mock aus demselben Schema wie Ihr Design und Ihre Tests stammt, bleibt er synchron mit dem Vertrag. Das ist der Teil, den handgeschriebene Handler nicht garantieren können. Wenn Sie sehen möchten, wie sich die Schema-zu-Mock-Generierung zwischen verschiedenen Tools vergleicht, stellt diese Zusammenstellung der besten API-Mocking-Tools die Optionen nebeneinander.
Eine praktische Aufteilung, für die sich viele Teams entscheiden:
- MSW für Komponenten- und Unit-Tests innerhalb des Frontend-Repos behalten.
- Einen gehosteten Mock für teamübergreifende Integration, Demos und jeden Nicht-JS-Konsumenten verwenden.
Sie wählen nicht nur eines aus. Sie verwenden jedes dort, wo es passt. Laden Sie Apidog herunter, wenn Sie die gehostete Seite neben Ihrem bestehenden MSW-Setup ausprobieren möchten.
Weitere wissenswerte MSW-Alternativen
MSW ist nicht die einzige Mocking-Bibliothek, und eine Plattform ist nicht Ihre einzige Option. Je nach Ihrem Stack:
- Mockoon ist eine Desktop-App, um schnell lokale Mock-Server hochzufahren, mit einer GUI anstelle von Code.
- WireMock ist ein Java-basierter Mock-Server, stark für JVM-Teams und Contract Testing.
- Prism von Stoplight generiert einen Mock direkt aus einer OpenAPI-Datei über die Kommandozeile.
- json-server verwandelt eine JSON-Datei in eine schnelle REST-API für Prototyping.
Jedes Tool hat seine Kompromisse. WireMock und Prism tendieren zu Backend- und Vertragstests; Mockoon und json-server tendieren zu einem schnellen lokalen Setup. Wenn Ihr spezifisches Problem ist, „MSW kann meinen Nicht-JS-Teamkollegen nicht helfen“, löst jeder HTTP-basierte Mock-Server das Problem. Für einen breiteren Frontend-Blick sehen Sie, wie Teams das Mocking von APIs in React mit Axios handhaben.
Häufig gestellte Fragen
Ist MSW kostenlos?
Ja. Mock Service Worker ist Open Source unter der MIT-Lizenz und kann kostenlos in jedem Projekt verwendet werden, ob kommerziell oder nicht. Sie beginnen erst zu zahlen, wenn Sie zu einer gehosteten Plattform für gemeinsame Mocks wechseln, und Tools wie Apidog bieten auch dafür einen kostenlosen Tarif an.
Kann Apidog MSW in meinen Unit-Tests ersetzen?
Nein, und Sie sollten es auch nicht versuchen. MSW fängt Anfragen innerhalb Ihres JavaScript-Test-Runners ab. Apidog ist eine gehostete Plattform, keine importierbare Bibliothek, daher kann es nicht wie MSW in Jest oder Vitest sitzen. Verwenden Sie stattdessen Apidog für gemeinsame, teamübergreifende oder schema-gesteuerte Mocks. Wenn Sie sich rein auf die Test-Runner-Seite konzentrieren, behandelt diese Anleitung zum Mocken von API-Aufrufen die In-Code-Ansätze.
Funktioniert MSW in Node oder nur im Browser?
Beides. Im Browser verwendet MSW einen Service Worker. In Node patcht es die Request-Schicht, sodass dieselben Handler in Jest, Vitest oder jeder anderen Node-Testumgebung laufen. Dieser Dual-Modus ist eine seiner größten Stärken für Full-Stack-JS-Teams.
Wann sollte ich von MSW zu einem gehosteten Mock-Server wechseln?
Wechseln Sie, oder fügen Sie besser einen hinzu, wenn der Mock geteilt werden muss. Die klarsten Anzeichen: ein Nicht-JavaScript-Client benötigt ihn, mehrere Personen benötigen dieselbe stabile URL, oder Sie entwerfen APIs spezifikationsbasiert und möchten, dass Mocks automatisch aus OpenAPI generiert werden.
Fazit
MSW ist hervorragend darin, wofür es gebaut wurde: Anfragen innerhalb von JavaScript für Frontend- und Unit-Tests abzufangen. Es versucht nicht, ein gemeinsamer, gehosteter, sprachunabhängiger Mock zu sein, und das ist in Ordnung. Wenn Ihre Mocks das Repo verlassen müssen, wenn andere Sprachen oder andere Teams sie benötigen oder wenn Sie möchten, dass sie aus einer Spezifikation generiert werden, dann ist es an der Zeit, eine vollständige Plattform danebenzustellen.
Apidog übernimmt die gemeinsame, schema-gesteuerte Seite: ein gehosteter Mock-Server mit einer echten URL, automatischen Mocks aus Ihrem OpenAPI-Design und realistischen Daten out-of-the-box. Behalten Sie MSW dort, wo es stark ist, und lassen Sie Apidog alles abdecken, was über den Bereich Ihres Test-Runners hinausgeht. Laden Sie Apidog herunter und richten Sie Ihr Frontend auf einen gemeinsamen Mock, um den Unterschied zu sehen.