Ihr Code hängt von einem Dienst ab, den Sie nicht kontrollieren. Ein Zahlungsgateway, eine Partner-API, ein Legacy-Mainframe, ein Microservice eines anderen Teams. Diese Abhängigkeit ist wegen Wartungsarbeiten ausgefallen, begrenzt Ihre Testläufe, kostet pro Aufruf oder liefert fehlerhafte Daten. Dadurch stagniert Ihre Entwicklung und Ihre CI-Pipeline wird aus Gründen rot, die nichts mit Ihrem Code zu tun haben.
Service-Virtualisierung behebt dieses Problem. Sie ersetzen die reale Abhängigkeit durch einen Platzhalter, der sich wie die reale Abhängigkeit verhält, sodass Sie etwas entwickeln und testen können, das Sie vollständig kontrollieren. Dieser Leitfaden erklärt, was Service-Virtualisierung ist, wie sie sich von Mocking und Stubbing unterscheidet, warum Teams sie einsetzen und welche Tools dafür geeignet sind, mit echten Befehlen für WireMock, Hoverfly, Mountebank, die Enterprise-Optionen und Apidogs Mock-Server für die API-Vertrags-Virtualisierung.
Was Service-Virtualisierung ist
Service-Virtualisierung simuliert das Verhalten einer Abhängigkeit, die Sie nicht kontrollieren, sodass Ihre Anwendung mit der Simulation statt mit dem realen System kommunizieren kann.
Das Wort „Verhalten“ hat hier Gewicht. Ein guter virtueller Dienst gibt nicht nur eine feste Nutzlast zurück. Er stimmt sich mit Anfragedetails ab, gibt unterschiedliche Antworten für unterschiedliche Eingaben zurück, speichert den Zustand über Aufrufe hinweg, injiziert Latenz und Fehler und spricht dasselbe Protokoll wie das reale System. Ziel ist ein so realistischer Platzhalter, dass Ihr Code während der Entwicklung und des Tests den Unterschied nicht erkennen kann.
Der Begriff „API-Virtualisierung“ bedeutet dasselbe, wenn die Abhängigkeit eine HTTP-API ist, und „API-Simulator“ ist das Tool, das den virtuellen Endpunkt erzeugt. Behandeln Sie beides als Synonyme für den API-fokussierten Bereich der Service-Virtualisierung.
Service-Virtualisierung vs. Mocking vs. Stubbing
Diese drei Begriffe überschneiden sich, und die Leute verwenden sie locker. Hier ist eine praktische Methode, sie zu trennen.
Ein Stub gibt eine fest codierte Antwort zurück. Er ignoriert die Anfrage und antwortet immer auf dieselbe Weise. Wenn Ihr Test GET /user/42 aufruft und der Stub so eingestellt ist, dass er ein festes Benutzerobjekt zurückgibt, gibt er dasselbe Objekt zurück, egal welche ID Sie senden. Stubs sind die einfachste Form und leben in Ihrem Testcode.
Ein Mock ist ein Stub, der auch Interaktionen überprüft. Er zeichnet auf, wie er aufgerufen wurde (welche Methoden, welche Argumente, wie oft), damit Ihr Test bestätigen kann, dass Ihr Code die Abhängigkeit korrekt verwendet hat. Mocks sind ein Unit-Testing-Tool. Sie laufen normalerweise im Prozess, in derselben Sprache wie Ihr Code. Unser API-Stubbing vs. API-Mocking Erklärtext geht tiefer auf diese Unterscheidung ein.
Service-Virtualisierung arbeitet über das Netzwerk, nicht in Ihrem Code. Sie stellt einen laufenden Dienst auf einem realen Netzwerkport bereit, der ein reales Protokoll spricht. Ihre Anwendung verbindet sich damit auf die gleiche Weise, wie sie sich mit der Produktion verbinden würde, indem sie eine Basis-URL oder eine Proxy-Einstellung ändert. Ein virtueller Dienst kann zustandsbehaftet sein, komplexe Anforderungsbedingungen erfüllen und Protokollebenenverhalten wie HTTP-Statuscodes, Header, Streaming und Verbindungsfehler simulieren.
Die Grenze zwischen „Mock“ und „Service-Virtualisierung“ ist im täglichen Sprachgebrauch verschwommen. Viele Teams nennen einen laufenden HTTP-Mock-Server „einen Mock“, auch wenn er eine vollständige Virtualisierung vornimmt. Das ist in Ordnung. Die Unterscheidung, die zählt: Ersetzen Sie ein Objekt innerhalb Ihres Prozesses (Mocking/Stubbing) oder stellen Sie einen vernetzten Dienst bereit, mit dem sich Ihre App verbindet (Virtualisierung)? Weitere Informationen zur Mock-Seite finden Sie unter API-Mocking: Alles, was Sie wissen müssen.
Warum Teams Service-Virtualisierung verwenden
Drei Probleme treiben die meisten Anwendungsfälle voran.
Die Abhängigkeit ist nicht bereit. Frontend- und Backend-Teams arbeiten parallel, und das Frontend benötigt eine funktionierende API, bevor das Backend sie bereitstellt. Ein virtueller Dienst, der auf Basis des API-Vertrags erstellt wurde, ermöglicht es dem Frontend, heute mit realistischen Antworten zu arbeiten. Niemand wartet.
Die Abhängigkeit ist teuer oder ratenbegrenzt. Drittanbieter-APIs berechnen oft pro Aufruf oder drosseln aggressiv, sodass das Ausführen einer vollständigen Testsuite gegen eine Live-Sandbox Kontingent und Geld verbraucht. Ein virtueller Dienst kann kostenlos aufgerufen werden, sodass Ihre CI täglich Tausende von Szenarien ausführen kann.
Die Abhängigkeit ist instabil oder schwer zu kontrollieren. Sie können einen echten Zahlungsanbieter nicht einfach dazu bringen, einen bestimmten Fehler zurückzugeben, ein Timeout zu verursachen oder eine fehlerhafte Antwort zu senden. Ein virtueller Dienst erzeugt all dies auf Abruf, wodurch Sie die Fehlerpfade testen können, die in der Produktion auftreten.
Es gibt auch einen Kontrollvorteil. Echte Abhängigkeiten haben Daten, die sich unter Ihnen ändern. Ein virtueller Dienst gibt Ihnen einen festen, bekannten Zustand, sodass Ihre Tests deterministisch sind. Ein grüner Build bedeutet, dass Ihr Code funktioniert, und nicht, dass sich ein entferntes System heute zufällig richtig verhalten hat.
Wie Service-Virtualisierung funktioniert
Die meisten Tools folgen einem von zwei Mustern.
Aufzeichnen und Wiedergeben. Sie richten das Tool als Proxy auf den realen Dienst, leiten einmal echten Traffic hindurch, und es erfasst die Anfrage-/Antwortpaare. Später gibt es diese Aufzeichnungen wieder, anstatt den realen Dienst aufzurufen. Das ist schnell, weil Sie keine Antworten manuell schreiben müssen. Der Capture-Modus von Hoverfly und der Record-Modus von WireMock funktionieren beide auf diese Weise.
Spezifikationsbasiert. Sie definieren den virtuellen Dienst anhand eines API-Vertrags oder manuell: Sie deklarieren, welche Anfragen zu welchen Antworten passen, fügen dynamische Werte hinzu und richten zustandsbehaftetes Verhalten ein. Das ist anfangs mehr Arbeit, gibt Ihnen aber die volle Kontrolle und funktioniert auch, wenn der reale Dienst noch nicht existiert.
In beiden Fällen ist der Kernmechanismus das Anfrage-Matching. Wenn eine Anfrage eingeht, prüft das Tool diese anhand einer Reihe von Regeln (Pfad, Methode, Abfrageparameter, Header, Body) und gibt die Antwort zurück, die der ersten Übereinstimmung zugeordnet ist. Bessere Tools fügen Templating hinzu, sodass eine Antwort Teile der Anfrage widerspiegeln oder bei jedem Aufruf neue Werte generieren kann. So fühlt sich ein virtueller Dienst lebendig statt statisch an.
Die Tools
Hier sind die wichtigsten Optionen, von Open-Source-Tools mit HTTP-Fokus bis hin zu umfangreichen Enterprise-Suiten. Überprüfen Sie aktuelle Versionen und Funktionen anhand der Dokumentation jedes Projekts, bevor Sie sich festlegen, da sich diese schnell weiterentwickeln.
WireMock
WireMock ist ein Open-Source-Tool für API-Mocking und Service-Virtualisierung für HTTP. Es läuft als eigenständiger Prozess, eingebettet in JVM-Tests oder in einem Container. Sie definieren Stub-Mappings als JSON, und WireMock gleicht eingehende Anfragen damit ab. Es unterstützt das Aufzeichnen und Wiedergeben gegen einen realen Dienst, Antwort-Templating, zustandsbehaftete Szenarien, Fehlerinjektion und simulierte Verzögerungen.
java -jar wiremock-standalone-3.13.2.jar --port 8080
Registrieren Sie dann einen Stub über seine Admin-API:
curl -X POST http://localhost:8080/__admin/mappings \
-H "Content-Type: application/json" \
-d '{
"request": {
"method": "GET",
"url": "/user/42"
},
"response": {
"status": 200,
"headers": { "Content-Type": "application/json" },
"jsonBody": { "id": 42, "name": "Ada Lovelace" }
}
}'
WireMock ist am stärksten, wenn Ihre Abhängigkeiten HTTP sind und Sie eine feingranulare Kontrolle in JVM- oder containerisierten Setups wünschen. Es gibt eine kommerzielle gehostete Version (WireMock Cloud), wenn Sie eine verwaltete Option wünschen.
Hoverfly
Hoverfly ist ein leichtgewichtiges Open-Source-Tool für Service-Virtualisierung, geschrieben in Go. Es funktioniert als Proxy: Sie leiten den ausgehenden Traffic Ihrer Anwendung durch Hoverfly, und es zeichnet entweder reale Antworten auf oder spielt simulierte Antworten wieder ab. Es läuft in verschiedenen Modi, einschließlich Capture, Simulate, Spy, Modify, Synthesize und Diff.
Ein grundlegender Capture-then-Replay-Flow mit dem Befehl hoverctl:
hoverctl start
hoverctl mode capture
curl --proxy http://localhost:8500 https://api.example.com/user/42
hoverctl export simulation.json
hoverctl mode simulate
Hoverflys Admin-API läuft standardmäßig auf Port 8888 und sein Proxy auf 8500. Das Record-and-Replay-Proxy-Modell ist gut geeignet, wenn Sie bestehenden Traffic schnell virtualisieren möchten, anstatt jede Antwort manuell zu schreiben. Es gibt auch eine gehostete Hoverfly Cloud.
Mountebank
Mountebank ist ein Open-Source-Tool, das um „Imposter“ herum aufgebaut ist. Ein Imposter ist ein einzelner virtueller Dienst, der auf einem Port lauscht und ein Protokoll spricht. Neben HTTP und HTTPS unterstützt Mountebank auch TCP und SMTP, was nützlich ist, wenn Ihre Abhängigkeit keine einfache REST-API ist. Sie steuern es vollständig über eine REST-Steuerungsebene auf Port 2525.
Installieren und starten Sie es:
npm install -g mountebank
mb
Erstellen Sie dann einen Imposter, indem Sie JSON an den Kontrollport POSTen:
curl -X POST http://localhost:2525/imposters \
-H "Content-Type: application/json" \
-d '{
"port": 4545,
"protocol": "http",
"stubs": [{
"predicates": [{ "equals": { "method": "GET", "path": "/user/42" } }],
"responses": [{ "is": { "statusCode": 200, "body": "{\"id\":42,\"name\":\"Ada Lovelace\"}" } }]
}]
}'
Prädikate entscheiden, welche Anfrage übereinstimmt; Antworten definieren, was zurückkommt. Die Multi-Protokoll-Fähigkeit von Mountebank ist sein Unterscheidungsmerkmal unter den Open-Source-Optionen.
Parasoft Virtualize und Broadcom Service Virtualization
Für große Unternehmen sind die Schwergewichte Parasoft Virtualize und Broadcom Service Virtualization (Teil der DevTest-Suite). Dies sind kommerzielle Plattformen, die für Teams entwickelt wurden, die viele Protokolle und Nachrichtenformate jenseits von HTTP simulieren, virtuelle Dienste mit realen Datenquellen verbinden und die Virtualisierung über viele Umgebungen hinweg zentral verwalten müssen.
Parasoft Virtualize bewirbt die Unterstützung einer breiten Palette von Industriestandardprotokollen und Nachrichtenformaten sowie datengesteuerte virtuelle Dienste, die aus externen Datenquellen gespeist werden. Das Angebot von Broadcom zielt auf ähnliche Unternehmensszenarien mit virtualisierten Umgebungen für die parallele Entwicklung und das Testen ab. Beide sind mit Enterprise-Lizenzen und Einrichtungsaufwand verbunden, daher eignen sie sich, wenn Sie Legacy-Protokolle (Mainframe, MQ, Nachrichten fester Länge) im großen Maßstab virtualisieren, anstatt eine Handvoll REST-Endpunkte. Wenn Ihre Abhängigkeiten gewöhnliche HTTP-APIs sind, decken die oben genannten Open-Source-Tools oder eine API-Plattform Sie zu einem Bruchteil der Kosten ab. Bestätigen Sie aktuelle Protokolllisten und Preise mit jedem Anbieter.
Apidog: leichtgewichtige Service-Virtualisierung für API-Verträge
Wenn die Abhängigkeit, die Sie virtualisieren müssen, eine durch einen Vertrag definierte HTTP-API ist, deckt Apidog diesen Bereich ohne ein separates Tool ab. Wenn Sie eine API entwerfen oder importieren, stellt Apidog automatisch einen Mock-Server dafür bereit. Ihr Frontend oder Ihre Testsuite erhält einen funktionierenden Endpunkt allein aus dem Schema, bevor Backend-Code existiert.
Was dies näher an die Virtualisierung als an einen einfachen Stub heranbringt, ist, dass Apidogs Mock schema-basiert und dynamisch ist. Sein Smart Mock liest Ihr JSON-Schema und generiert Antworten, die jede Einschränkung (Typen, Formate, Enums, Pflichtfelder) respektieren. Es gleicht auch Feldnamen mit integrierten Regeln ab, sodass ein Feld namens email eine gültige E-Mail und ein Feld namens city einen Städtenamen zurückgibt, anstatt Platzhaltermüll. Für eine feinere Kontrolle generieren dynamische Werte, basierend auf Faker.js, realistische Daten bei jedem Aufruf, und Sie können feste Werte festlegen, wo Sie Determinismus benötigen.
Sie können auch benutzerdefinierte Mock-Regeln schreiben, die unterschiedliche Antworten basierend auf Anforderungsparametern zurückgeben, was das Anforderungs-Matching-Verhalten ist, das Virtualisierung von einem festen Stub trennt. Der Mock-Server läuft in der GUI oder headless, sodass er sowohl für die lokale Entwicklung als auch für CI geeignet ist. Eine exemplarische Vorgehensweise finden Sie unter Wie man eine API in einer Minute mockt.
Wo Apidog passt: API-Vertrags-Service-Virtualisierung für HTTP/REST und Ähnliches. Wo es nicht passt: Es ist kein proxy-basiertes Record-and-Replay-Tool für beliebige Legacy-Protokolle und kein Lastgenerator. Dafür sind die oben genannten Tools die richtige Wahl. Für einen breiteren Tool-für-Tool-Vergleich siehe Online-API-Mocking-Tools im Vergleich und Die 10 besten API-Mocking-Tools.
So fangen Sie an
Passen Sie das Tool an die Abhängigkeit an, nicht umgekehrt.
- Protokoll identifizieren. Reines HTTP/REST? Fast alles funktioniert hier, und eine API-Plattform bietet die geringste Reibung. Benötigen Sie TCP oder SMTP? Mountebank. Legacy-Enterprise-Protokolle im großen Maßstab? Parasoft oder Broadcom.
- Entscheiden Sie zwischen Aufzeichnen und Spezifizieren. Wenn der reale Dienst existiert und Sie den Traffic darüber leiten können, ist Record-and-Replay (Hoverfly, WireMock Record-Modus) am schnellsten. Wenn er noch nicht existiert, leiten Sie den virtuellen Dienst aus dem API-Vertrag ab (Apidog, WireMock Stubs, Mountebank Imposters).
- Richten Sie Ihre App darauf aus. Ändern Sie eine Basis-URL oder Proxy-Einstellung in Ihrer Test- oder Entwicklungsumgebung und hinterlegen Sie dies in der Konfiguration, damit das Umschalten zwischen virtuell und real eine einzige Variable ist.
- Fügen Sie die Fehlerfälle hinzu. Der Vorteil ist das Testen von Fehlerpfaden. Fügen Sie daher Antworten für 4xx und 5xx, Timeouts und fehlerhafte Bodies hinzu. Das ist der Teil, den reale Abhängigkeiten Sie nicht proben lassen.
- Führen Sie es in der CI aus. Ein virtueller Dienst, der nur auf Ihrem Laptop läuft, hilft Ihnen, aber nicht dem Build. Fügen Sie ihn in die Pipeline ein, damit grün auch wirklich grün bedeutet. Wenn Sie einen Mock benötigen, der headless in der CI ohne GUI läuft, siehe Headless API Mock Tools.
Für den Kompromiss zwischen virtuellen und realen Abhängigkeiten im Allgemeinen, erklärt Mock-Server vs. realer Server, wann Sie welche verwenden sollten.
FAQ
Ist Service-Virtualisierung dasselbe wie Mocking? Nicht ganz. Mocking ersetzt normalerweise ein Objekt innerhalb Ihres Prozesses für Unit-Tests und überprüft, wie es aufgerufen wurde. Service-Virtualisierung stellt einen laufenden Dienst auf einem Netzwerkport bereit, mit dem sich Ihre Anwendung über ein reales Protokoll verbindet. Im umgangssprachlichen Gebrauch werden HTTP-basierte virtuelle Dienste oft als „Mocks“ bezeichnet, was in Ordnung ist, aber die technische Unterscheidung liegt zwischen einem In-Process-Objekt und einem vernetzten Dienst.
Wann sollte ich einen virtuellen Dienst anstelle einer realen Testumgebung verwenden? Verwenden Sie Virtualisierung, wenn die reale Abhängigkeit nicht verfügbar, ratenbegrenzt, teuer oder schwer zu kontrollieren ist. Sie bietet Ihnen deterministische, kostenlose, stets verfügbare Antworten und ermöglicht es Ihnen, Fehler zu simulieren, die Sie im realen System nicht auslösen können. Behalten Sie einen kleineren Satz von Tests gegen den realen Dienst für die endgültige Integrationssicherheit bei.
Kann ein virtueller Dienst zustandsbehaftet sein? Ja. Tools wie WireMock und Mountebank unterstützen zustandsbehaftete Szenarien, bei denen sich die Antwort basierend auf früheren Anfragen ändert, z. B. die Rückgabe eines leeren Warenkorbs und anschließend eines Warenkorbs mit Artikeln nach einem POST. Dies ist wichtig, wenn Sie Workflows und nicht einzelne Aufrufe simulieren.
Brauche ich ein kostenpflichtiges Enterprise-Tool? Nur wenn Sie viele Nicht-HTTP-Protokolle virtualisieren oder die Virtualisierung in einer großen Organisation verwalten. Für gewöhnliche HTTP-APIs erledigen Open-Source-Tools (WireMock, Hoverfly, Mountebank) oder ein API-Plattform-Mock-Server die Aufgabe ohne Enterprise-Lizenzierung.
Was ist der schnellste Weg, eine HTTP-API aus ihrer Spezifikation zu virtualisieren? Importieren Sie die API-Definition in ein Tool, das einen Mock aus dem Schema generiert. Apidog macht dies automatisch: Importieren Sie Ihre OpenAPI-Spezifikation und Sie erhalten einen schema-basierten Mock-Server mit realistischen dynamischen Daten, ohne dass Sie Antworten schreiben müssen. Von dort aus fügen Sie benutzerdefinierte Regeln für die spezifischen Anfrage-/Antwortbedingungen hinzu, die Ihre Tests benötigen.