Kurz gesagt (TL;DR)
SoapUI-Mock-Services simulieren SOAP- oder REST-Endpunkte lokal, erfordern jedoch einen laufenden Java-Prozess, manuelle Dispatch-Konfigurationen und sind ohne gemeinsam genutzte Maschine nicht teamübergreifend nutzbar. Apidogs Smart Mock generiert Mock-Antworten direkt aus Ihrem API-Schema, läuft in der Cloud und ist automatisch für das gesamte Team zugänglich.
💡 Apidog ist eine kostenlose All-in-One-API-Entwicklungsplattform mit integriertem Smart Mock, die sofort Mock-Endpunkte aus Ihren API-Definitionen erstellt – ohne lokalen Java-Prozess. Testen Sie Apidog kostenlos, keine Kreditkarte erforderlich.
Einleitung
Mock-Services sind in der API-Entwicklung unverzichtbar: Sie testen Client-Code gegen einen simulierten Dienst, bevor dieser verfügbar ist, oder prüfen Fehlerfälle und Latenzen, ohne reale Systeme zu beeinflussen.
SoapUI-Mock-Services existieren seit den ersten Versionen. Sie betreiben einen lokalen HTTP-Server, der Anfragen gemäß Ihren Regeln beantwortet. Der Nachteil: Der Prozess läuft nur solange SoapUI läuft, ist schwer teamübergreifend zugänglich und die Konfiguration ist umständlich.
In diesem Guide lernst du, wie du SoapUI-Mock-Services praktisch einrichtest, welche typischen Probleme in Teams auftauchen und wie Apidog diese Herausforderungen anders löst.
Wie SoapUI-Mock-Services funktionieren
SoapUI erstellt Mock-Services aus bestehenden SOAP- oder REST-Schnittstellen deines Projekts. Das Prinzip:
- Lauscht auf einem konfigurierten lokalen Port (z. B.
http://localhost:8088/MockService) - Fängt eingehende Anfragen ab
- Vergleicht die Anfrage mit einer „Mock-Antwort“ (Dispatch-Logik)
- Gibt die konfigurierte Antwort zurück
Für SOAP-Services kann SoapUI direkt aus der WSDL Mock-Antworten generieren. So simulierst du einen Dienst, bevor er produktiv ist oder ein echter Endpunkt existiert.
Einrichtung eines SoapUI-Mock-Services (Schritt für Schritt)
Für eine SOAP-Schnittstelle
- Klicke im SoapUI-Projektbaum mit Rechtsklick auf eine SOAP-Schnittstelle.
- Wähle „MockService generieren“.
- Im Dialog:
- Dienstname festlegen (z. B. „OrderService Mock“)
- Portnummer einstellen (Standard: 8088; ggf. ändern)
- Pfad setzen (z. B.
/orders)
- Bestätige mit OK. SoapUI erstellt einen MockService-Knoten.
- Öffne den MockService-Knoten: Für jede SOAP-Operation gibt es eine MockOperation.
- Doppelklicke eine MockOperation, um den Mock-Antworteditor zu öffnen.
- Passe das SOAP-Antwort-XML an, um gewünschte Werte zu simulieren.
- Starte den lokalen Server per „Play“-Button im MockService-Editor.
Dein Mock läuft jetzt unter http://localhost:8088/orders. Weise deinen Client auf diese URL.
Für eine REST-Schnittstelle
- Rechtsklick auf eine REST-Schnittstelle/Ressource im Projektbaum.
- „Zu MockService hinzufügen“ oder „MockService generieren“ auswählen.
- Port und Pfad wie oben konfigurieren.
- Für jede Ressource/Methode: Mock-Antworttext und Statuscode festlegen.
- Mock-Service starten.
Dispatch konfigurieren
Standardmäßig gibt SoapUI die erste gefundene Mock-Antwort zurück. Für unterschiedliche Antworten je nach Anfrage:
- SEQUENCE Dispatch: Antworten werden nacheinander ausgegeben (z. B. Aufruf 1 → Antwort A, Aufruf 2 → Antwort B).
- SCRIPT Dispatch: Ein Groovy-Skript prüft die Anfrage und gibt den Antwortnamen zurück.
Beispiel-Dispatch-Skript:
def request = mockRequest.getRequestContent()
if (request.contains("orderId>12345")) {
return "OrderFoundResponse"
} else {
return "OrderNotFoundResponse"
}
Lege dazu mehrere benannte Mock-Antworten an (z. B. „OrderFoundResponse“, „OrderNotFoundResponse“), das Dispatch-Skript entscheidet je nach Anfrage.
Häufige Probleme mit SoapUI-Mock-Services
Problem 1: Mock stoppt, wenn SoapUI geschlossen wird
SoapUI-Mocks laufen im JVM-Prozess von SoapUI. Wird SoapUI beendet, wird auch der Mock gestoppt – und für andere unzugänglich.
Workarounds:
- SoapUI auf einer dedizierten Maschine/VM offen halten
- SoapUI-CLI nutzen:
mockservicerunner.sh -p 8088 -s "OrderService Mock" project.xml - Einen persistenten Server im Team betreiben
Der Aufwand bleibt: Java und SoapUI müssen installiert bleiben.
Problem 2: Teilen des Mock im Team
Ein Mock auf localhost:8088 ist nur lokal verfügbar. Für Teamzugriff sind Firewall/VPN oder ein geteilter Server nötig.
Problem 3: Dispatch-Skripte brechen bei komplexem XML
Dispatch-Skripte in Groovy nutzen String-Matching auf rohem XML. Bei unterschiedlichen Namensraum-Präfixen (z. B. <ns1:orderId>) schlagen einfache Suchen fehl.
Lösung: Nutze XML-Parsing mit GroovyUtils. Das erhöht jedoch die Komplexität.
Problem 4: Zustand wird nicht zwischen Aufrufen beibehalten
SoapUI-Mocks sind zustandslos. Für Workflows wie „Create-then-Read“ musst du Groovy-Dispatch-Skripte mit Shared-Variablen schreiben – fehleranfällig und schwer wartbar.
Problem 5: SSL für Mock-Services
HTTPS erfordert Keystore-Konfiguration, Anpassung der SoapUI-SSL-Einstellungen und passende Zertifikate im Client. Für einfache HTTP-Mocks nicht notwendig, aber für realistische Tests oft gefordert und aufwendig.
Apidog Smart Mock: Der Vergleich
Apidogs Mock-Lösung setzt beim API-Design an, nicht beim Prozess.
Workflow:
- Definiere einen API-Endpunkt (Methode, Pfad, Anfrage- und Antwortschema) in Apidog
- Apidog generiert automatisch einen Mock-Endpunkt in der Cloud – keine weitere Konfiguration nötig
Beispiel-URL:
https://{ihr-projekt}.mock.apidog.io/orders/{id}
Vorteile:
- Immer erreichbar (keine lokalen Prozesse)
- Für alle Teammitglieder im Projekt direkt zugänglich
- Antwortdaten werden aus dem Schema generiert
Wie Apidog Mock-Antworten generiert
Apidog liest deine Antwortdefinition (z. B. OpenAPI/JSON Schema) und erzeugt realistische Fakedaten. Beispielsweise:
-
orderIdals"string"im UUID-Format → zufällige UUID -
amountals"number"zwischen 0 und 10000 → Zahl im Bereich
Du kannst für bestimmte Felder auch feste Mock-Regeln anlegen, z. B. orderId = "test-123".
SOAP-Endpunkte in Apidog Mock
Apidogs Smart Mock ist für REST-APIs mit JSON konzipiert. Für SOAP-Endpunkte:
- Lege eine Anfrage in Apidog an
- Definiere eine benutzerdefinierte Antwort (SOAP-Envelope als XML)
- Apidogs Mock-Server liefert diese Antwort aus
Automatisches Stub-Generieren aus WSDL gibt es nicht, aber einfache SOAP-Mocks sind möglich.
Zustandsbehaftetes Mocking
Über JavaScript-Mock-Skripte kannst du eingehende Requests prüfen (Body, Header etc.) und abhängig davon gezielt unterschiedliche Antworten liefern – ähnlich zu Groovy-Dispatch in SoapUI, 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
SoapUI-Mock-Services eignen sich, wenn:
- Du einen WSDL-basierten SOAP-Dienst schnell stubben willst
- Dein Team offline oder hinter restriktiven Firewalls arbeitet
- Ihr fest im SoapUI-Ökosystem seid und keine neuen Tools einführen wollt
Apidog Smart Mock empfiehlt sich, wenn:
- Du REST-Endpunkte für dein Team ohne Netzwerkkonfiguration freigeben willst
- Mocks dauerhaft und ohne manuelles Starten verfügbar sein sollen
- Du APIs zuerst als Vertrag definierst („Contract first“)
- Du keine Java-Umgebung für Mocks pflegen willst
FAQ
Kann ich SoapUI-Mocks headless (ohne GUI) laufen lassen?
Ja, mit mockservicerunner.sh (Linux/macOS) oder mockservicerunner.bat (Windows). Beispiel:
mockservicerunner.sh -p 8088 -s "OrderService Mock" project.xml
Unterstützt Apidog SOAP-Mock-Services?
Teilweise – du kannst benutzerdefinierte SOAP-XML-Antworten konfigurieren. Automatische Stub-Generierung wie in SoapUI gibt es nicht.
Kann SoapUI langsame Antworten simulieren?
Ja, mit einem Delay-Wert in der Mock-Antwort. Apidog bietet ebenfalls Antwortverzögerungen.
Wie viele Mock-Anfragen kann Apidog verarbeiten?
Cloud-Mocks von Apidog sind für typische Entwicklungs- und Testlasten ausgelegt. Für Massentests ggf. spezialisierte Tools nutzen.
Unterschiedliche Mock-Antworten für denselben Endpunkt im Team?
In SoapUI kann jeder seinen Mock individuell anpassen. In Apidog: Nutze mehrere Umgebungen, Query-Parameter oder die „Mock expects“-Funktion, um Bedingungen und spezifische Antworten zu definieren.
Muss ich meine API in Apidog komplett definieren?
Ein Antwortschema ist hilfreich, aber keine Pflicht. Du kannst auch manuelle Mock-Antworten ohne vollständiges Schema anlegen.
Fazit: SoapUI-Mocks funktionieren, sind aber an lokale Prozesse gebunden. Für moderne Teams, die ständig verfügbare und geteilte Mocks brauchen, ist der Cloud-Ansatz von Apidog effizienter.
Top comments (0)