Kurz gesagt (TL;DR)
SoapUI-Mock-Services simulieren SOAP- oder REST-Endpunkte lokal, erfordern aber einen laufenden Java-Prozess, eine manuelle Dispatch-Konfiguration und können ohne eine gemeinsam genutzte Maschine nicht teamübergreifend geteilt werden. Apidogs Smart Mock generiert Mock-Antworten aus Ihrem API-Schema, läuft in der Cloud und wird automatisch mit Ihrem Team geteilt.
Einleitung
Mock-Services lösen ein häufiges Problem in der API-Entwicklung: Sie möchten testen, wie Ihr Client-Code einen Dienst verarbeitet, bevor dieser Dienst bereit ist, oder Sie möchten Randfälle (Fehler, langsame Antworten) testen, ohne diese in einem realen System zu verursachen.
Die Mock-Service-Funktion von SoapUI ist seit den frühen Versionen verfügbar und funktioniert. Sie betreibt einen lokalen HTTP-Server, der auf Anfragen gemäß den von Ihnen konfigurierten Regeln antwortet. Das Problem ist, dass dieser lokale Prozess Reibung erzeugt: Er stirbt, wenn Sie SoapUI schließen, andere Teammitglieder können ohne Netzwerk-Tricks nicht darauf zugreifen und die Konfigurationsoberfläche ist umständlich.
Dieser Leitfaden behandelt, wie SoapUI-Mock-Services funktionieren, wie man sie einrichtet, auf welche häufigen Probleme Teams stoßen und wie sich Apidogs Ansatz vergleicht.
Wie SoapUI-Mock-Services funktionieren
SoapUI erstellt Mock-Services aus bestehenden SOAP- oder REST-Schnittstellen in Ihrem Projekt. Der Mock-Service:
- Lauscht auf einem von Ihnen konfigurierten lokalen Port (z. B.
http://localhost:8088/MockService) - Fängt eingehende Anfragen ab
- Gleicht die Anfrage mit einer „Mock-Antwort“ mithilfe der Dispatch-Logik ab
- Gibt die konfigurierte Antwort zurück
Für SOAP-Services kann SoapUI Mock-Antworten automatisch aus Ihrer WSDL generieren und Stub-Antworten für jede Operation erstellen. Dies ist nützlich, um einen Dienst zu simulieren, bevor er existiert oder bevor Sie Zugriff auf den realen Endpunkt haben.
Einrichtung eines SoapUI-Mock-Services (Schritt für Schritt)
Für eine SOAP-Schnittstelle
- Klicken Sie in Ihrem SoapUI-Projekt im Projektbaum mit der rechten Maustaste auf eine SOAP-Schnittstelle.
- Wählen Sie „MockService generieren“.
- Konfigurieren Sie im Dialog:
- Dienstname (z. B. „OrderService Mock“)
- Portnummer (Standard ist 8088; ändern Sie diese, wenn dieser Port belegt ist)
- Pfad (z. B.
/orders)
- Klicken Sie auf OK. SoapUI erstellt einen MockService-Knoten in Ihrem Projektbaum.
- Erweitern Sie den MockService-Knoten. Sie sehen eine „MockOperation“ für jede SOAP-Operation in der Schnittstelle.
- Doppelklicken Sie auf eine MockOperation, um den Mock-Antworteditor zu öffnen.
- Bearbeiten Sie das SOAP-Antwort-XML, um die Werte zurückzugeben, die Sie simulieren möchten.
- Klicken Sie im MockService-Editor auf die grüne Wiedergabetaste, um den lokalen Server zu starten.
Ihr Mock läuft jetzt unter http://localhost:8088/orders. Richten Sie Ihren Client-Code auf diese URL aus.
Für eine REST-Schnittstelle
- Klicken Sie im Projektbaum mit der rechten Maustaste auf eine REST-Schnittstelle oder -Ressource.
- Wählen Sie „Zu MockService hinzufügen“ oder „MockService generieren“.
- Konfigurieren Sie Port und Pfad wie oben.
- Konfigurieren Sie für jede Ressource/Methode den Mock-Antworttext und den Statuscode.
- Starten Sie den Mock-Service.
Dispatch konfigurieren
Standardmäßig gibt der SoapUI-Mock-Service die erste gefundene Mock-Antwort zurück. Wenn Sie unterschiedliche Antworten für unterschiedliche Eingaben wünschen, konfigurieren Sie ein „Dispatch-Skript“ (Groovy) oder verwenden Sie den Dispatch-Typ „SEQUENCE“.
Sequence Dispatch: Gibt Antworten in einer festen Reihenfolge bei aufeinanderfolgenden Aufrufen zurück. Aufruf 1 erhält Antwort A, Aufruf 2 erhält Antwort B.
SCRIPT Dispatch: Ein Groovy-Skript untersucht die Anfrage und gibt einen Antwortnamen basierend auf der Logik zurück.
Beispiel für ein Dispatch-Skript:
def request = mockRequest.getRequestContent()
if (request.contains("orderId>12345")) {
return "OrderFoundResponse"
} else {
return "OrderNotFoundResponse"
}
Sie erstellen mehrere benannte Mock-Antworten (z. B. „OrderFoundResponse“, „OrderNotFoundResponse“) und das Dispatch-Skript wählt basierend auf dem eingehenden Anfrageninhalt aus, welche zurückgegeben werden soll.
Häufige Probleme mit SoapUI-Mock-Services
Problem 1: Mock stoppt, wenn SoapUI geschlossen wird
Der Mock-Service von SoapUI läuft als Teil des SoapUI JVM-Prozesses. Wenn Sie SoapUI schließen, stoppt der Mock. Teammitglieder, die den Mock verwenden, verlieren ihn.
Workarounds:
- SoapUI auf einer dedizierten Maschine oder VM offen halten
- Verwenden Sie die Befehlszeilenoption des SoapUI-Mock-Servers:
mockservicerunner.sh -p 8088 -s "OrderService Mock" project.xml - Verwenden Sie eine persistent freigegebene Maschine, die den Mock immer ausführt
Nichts davon ist elegant. Die Befehlszeilenoption hilft, erfordert aber immer noch eine Maschine mit installiertem SoapUI und Java.
Problem 2: Teilen des Mock im Team
Ein Mock auf localhost:8088 ist nur für die Person zugänglich, die ihn ausführt. Damit Teammitglieder auf denselben Mock zugreifen können, benötigen Sie Netzwerkzugriff auf diese Maschine (Firewall-Regeln, VPN-Einrichtung) oder müssen den Mock auf einem freigegebenen Server ausführen.
Problem 3: Dispatch-Skripte brechen bei komplexem XML
SoapUI-Dispatch-Skripte verwenden Groovy-String-Matching auf dem rohen XML-Body. SOAP-Envelopes haben Namensräume, und derselbe logische Wert kann mit unterschiedlichen Namensraumpräfixen erscheinen, je nach Client. Skripte, die nach literalen Zeichenketten wie <orderId>12345</orderId> suchen, brechen, wenn das Präfix abweicht.
Die Behebung erfordert ein korrektes XML-Parsing im Dispatch-Skript mithilfe der GroovyUtils-Klasse von SoapUI, was die Komplexität erhöht.
Problem 4: Zustand wird nicht zwischen Aufrufen beibehalten
SoapUI-Mock-Services sind standardmäßig zustandslos. Wenn Sie einen Create-then-Read-Workflow (POST zum Erstellen, GET zum Abrufen) mocken möchten, benötigen Sie ein Groovy-Dispatch-Skript, das den Zustand in einer gemeinsam genutzten Variable speichert. Dies funktioniert, ist aber anfällig.
Problem 5: SSL für Mock-Services
Die Konfiguration von HTTPS für einen SoapUI-Mock-Service erfordert die Einrichtung eines Keystores, die Konfiguration der SSL-Einstellungen von SoapUI und die Ausrichtung der Clients auf das richtige Zertifikat. Dies ist erheblich aufwendiger als reine HTTP-Mocks.
Apidog Smart Mock: Der Vergleich
Apidogs Mock-Ansatz beginnt beim API-Design, nicht bei einem laufenden Prozess.
Wenn Sie einen API-Endpunkt in Apidog definieren (Methode, Pfad, Anfrage-Schema, Antwort-Schema), generiert Apidog automatisch einen Mock-Endpunkt in der Cloud. Keine Konfiguration erforderlich.
Die Mock-URL sieht so aus: https://{ihr-projekt}.mock.apidog.io/orders/{id}
Diese URL ist:
- Immer aktiv (kein lokaler Prozess zum Starten oder Stoppen)
- Für jedes Teammitglied mit Zugriff auf das Projekt zugänglich
- Generiert Antworten aus dem von Ihnen definierten Schema
Wie Apidog Mock-Antworten generiert
Apidog liest Ihr Antwortschema (JSON Schema oder OpenAPI-Antwortdefinition) und generiert realistische Falschdaten. Ein Schema, das angibt, dass orderId ein string im UUID-Format ist, gibt eine zufällige UUID zurück. Ein Schema, das angibt, dass amount eine number zwischen 0 und 10000 ist, gibt eine Zahl in diesem Bereich zurück.
Sie können auch benutzerdefinierte Mock-Regeln für bestimmte Felder konfigurieren. Legen Sie fest, dass orderId immer "test-123" zurückgeben soll, wenn Sie einen vorhersagbaren Wert benötigen.
SOAP-Endpunkte in Apidog Mock
Apidogs Smart Mock ist für REST-Endpunkte mit JSON-Antworten konzipiert. Für SOAP-Endpunkte ist die Mock-Einrichtung manuell: Sie erstellen eine Anfrage in Apidog, konfigurieren eine benutzerdefinierte Antwort mit einem SOAP-Envelope und verwenden Apidogs Mock-Server, um diese zurückzugeben.
Dies ist weniger automatisiert als die WSDL-basierte Mock-Generierung von SoapUI, aber es funktioniert für Teams, die einen einfachen SOAP-Mock benötigen, ohne einen lokalen Java-Prozess ausführen zu müssen.
Zustandsbehaftetes Mocking
Apidog unterstützt benutzerdefinierte Antwortskripte für zustandsbehaftetes Mock-Verhalten. Sie können den Anfrage-Body in einem JavaScript-Mock-Skript überprüfen und basierend auf dem Anfrageninhalt unterschiedliche Antworten zurückgeben, ähnlich wie SoapUI-Dispatch-Skripte, aber in JavaScript.
Direkter Vergleich
| Funktion | SoapUI Mock | Apidog Smart Mock |
|---|---|---|
| Benötigt Java | Ja | Nein |
| Immer aktiv | Nur mit Befehlszeilen-Runner | Ja (Cloud) |
| Teamzugänglich | Manuelle Netzwerk-Konfiguration | Ja, über freigegebene URL |
| WSDL-Auto-Generierung | Ja | Nein |
| REST-Schema-basiert | Nein | Ja |
| Dynamische Antworten | Groovy-Dispatch | JavaScript-Mock-Skripte |
| HTTPS-Unterstützung | Manuelle Keystore-Einrichtung | Integriert |
| Zustandsbehaftetes Mocking | Über Groovy-Variablen | Über JavaScript-Skripte |
| Kostenlos | Ja | Ja |
Wann man welches Tool verwenden sollte
Verwenden Sie SoapUI-Mock-Services, wenn:
- Sie einen WSDL-basierten SOAP-Dienst mocken müssen und automatisch generierte Antwort-Stubs wünschen
- Ihr Team offline oder hinter strengen Netzwerkkontrollen arbeitet
- Sie bereits tief im SoapUI-Ökosystem verankert sind und die Tools nicht wechseln möchten
Verwenden Sie Apidog Smart Mock, wenn:
- Ihr Team REST-Endpunkte mockt und gemeinsamen Zugriff ohne Netzwerkeinrichtung benötigt
- Sie Mock-Server wünschen, die ohne manuelle Eingriffe ständig laufen
- Sie ein neues Projekt starten und den API-Vertrag vor der Implementierung definieren
- Sie die Installation und Wartung einer Java-Umgebung für Mock-Services vermeiden möchten
FAQ
Kann ich SoapUI-Mock-Services headless (ohne GUI) ausführen?Ja. SoapUI enthält mockservicerunner.sh (Linux/macOS) und mockservicerunner.bat (Windows). Führen Sie sie mit dem Projektdateipfad und dem Dienstnamen aus. Sie benötigen immer noch Java, aber die GUI muss nicht geöffnet sein.
Unterstützt Apidog SOAP-Mock-Services?Teilweise. Sie können benutzerdefinierte Antworten mit SOAP-XML im Mock-Server von Apidog konfigurieren. Sie erhalten keine WSDL-basierte automatische Generierung von Stub-Antworten. Für Teams mit gut verstandenen SOAP-Schnittstellen ist die manuelle Einrichtung beherrschbar.
Können SoapUI-Mock-Services langsame Antworten simulieren?Ja. In der Mock-Antwortkonfiguration stellen Sie einen „Delay“-Wert in Millisekunden ein. Apidog unterstützt auch die Konfiguration von Antwortverzögerungen zur Simulation langsamer Netzwerkbedingungen.
Wie viele Mock-Anfragen kann Apidog verarbeiten?Apidogs Cloud-Mock-Server bewältigt typische Entwicklungs- und Testlasten. Für hochvolumige Performance-Tests ist möglicherweise ein spezielles Mock-Server-Tool besser geeignet.
Was passiert, wenn zwei Teammitglieder unterschiedliche Mock-Antworten für denselben Endpunkt benötigen?In SoapUI führt jede Person ihren eigenen lokalen Mock aus und kann ihn unabhängig konfigurieren. In Apidog können Sie mehrere Umgebungen erstellen oder Abfrageparameter verwenden, um verschiedene Antwortszenarien auszuwählen. Die „Mock expects“-Funktion von Apidog ermöglicht es Ihnen, spezifische Anfragenbedingungen mit spezifischen Antworten abzugleichen.
Benötigt Apidogs Mock, dass die API zuerst vollständig definiert ist?Ein Antwortschema hilft Apidog, realistische Daten zu generieren, aber Sie können manuelle Mock-Antworten ohne vollständiges Schema erstellen. Definieren Sie den Endpunkt, legen Sie einen benutzerdefinierten Antwortkörper fest, und der Mock funktioniert.
Der Mock-Service von SoapUI ist funktional, aber an einen lokalen Java-Prozess gebunden. Für moderne Teams, die persistente, gemeinsam genutzte Mocks benötigen, beseitigt Apidogs Cloud-basierter Ansatz den Koordinationsaufwand.