Einen Service mocken, den du nicht kontrollierst
Der Fall ist immer derselbe: dein Ablauf geht durch einen Service, der nicht deiner ist, und du kommst nicht an ihn heran. Du hast heute kein VPN, er ist unten, ein anderes Team pflegt ihn, oder es gibt ihn schlicht noch nicht. Ein Mock macht den Nachmittag frei — und er ist auch der einfachste Weg, eine Woche lang gegen eine Lüge zu testen.
Zuerst: ist ein Mock das, was du brauchst?
Die entscheidende Frage ist nicht „komme ich an diesen Service heran?“, sondern „teste ich seine Antwort oder durchquere ich sie?“.
| Situation | Was benutzen | Warum |
|---|---|---|
| Du brauchst, dass er etwas zurückgibt, damit dein Ablauf weitergeht | Mock | Sein Inhalt ist nicht das, was du prüfst; er ist eine Vorbedingung |
| Du prüfst, wie dein Code auf das reagiert, was er zurückgibt | Der echte Service | Ein Stub wird dir sagen, alles sei gut, und du wirst es nicht wissen |
| Du jagst einen Fehler, der nur gegen das Echte auftritt | Die gemeinsame Umgebung | Der Fehler lebt im Unterschied zwischen Stub und Original |
| Es ist ein Integrationstest | Testcontainers oder ein Double im Test | Den Lebenszyklus steuert der Test, nicht du |
| Den Service gibt es noch nicht | Mock aus seinem Vertrag | Der Fall, in dem der Mock nicht lügen kann: er ist die einzige Quelle |
Das Risiko, das niemand erwähnt: der Stub bleibt stehen
Ein Mock friert einen Vertrag ein. Der echte Service ändert sich weiter, und dein Stub erfährt nichts davon: neue Felder, die du nicht zurückgibst, ein Fehlercode, der jetzt etwas anderes bedeutet, ein Datumsformat, das sich geändert hat. Dein Code besteht lokal und scheitert bei der Integration — genau das Problem, das der Mock zu vermeiden versprach.
Zwei Dinge verringern das erheblich, und keines davon ist „aufpassen“:
- Generiere den Stub aus dem Vertrag, nicht aus dem Gedächtnis. Gibt es ein OpenAPI, kommt das Antwortgerüst daher und wird neu erzeugt, wenn sich der Vertrag ändert.
- Schneide echte Aufrufe mit an dem Tag, an dem du Zugang hast, und mache Stubs daraus. Ein mitgeschnittenes Beispiel erfindet nichts.
Die vier Wege, es aufzusetzen
| Weg | Einstiegskosten | Wo es bricht |
|---|---|---|
| Ein Stub-Server (WireMock, MockServer) in deinem Compose | Ein Container mehr und seine Mapping-Dateien | Du musst trotzdem die URL des Aufrufers dorthin umleiten, in der Konfiguration eines fremden Repositories |
| Ein von Hand geschriebener Fake-Service | Eine halbe Stunde, und fertig | Er wird zu einem Projekt, das niemand pflegt und von dem niemand weiß, wem es gehört |
| Im HTTP-Client des Service selbst abfangen | Wenig, wenn das Framework es zulässt | Es ist falscher Code in deinem Repository, und irgendwer wird ihn committen |
| Ein in den Orchestrator eingebauter Mock | Das Werkzeug installieren | Es bindet die lokale Umgebung an jenes Werkzeug |
Beachte, dass drei der vier denselben Schmerzpunkt teilen, und es ist nicht das Schreiben des Stubs: es ist, den Aufrufer dazu zu bringen, zum Stub zu gehen. Das heißt, eine URL in der Konfiguration eines Repositories zu ändern, das oft nicht deines ist, und es rückgängig zu machen, wenn du den echten Service zurückwillst.
Wie Aseptic es macht
Aseptic behandelt „wohin ruft diese Abhängigkeit“ als erstklassige Entscheidung, nicht als
Dateiänderung. Für jede Abhängigkeit wählst du zwischen drei Zielen —dem lokalen Service,
deiner Cloud-Umgebung oder einem Mock— und die Engine schreibt die URL beim Start
um und injiziert sie als -D-Property oder Umgebungsvariable.
Praktische Folgen:
- Das Repository wird nicht angefasst. Nichts zu committen, nichts zurückzunehmen, nichts in einem Pull Request zu prüfen.
- Zurückgehen heißt, das Ziel zu ändern, nicht eine Änderung rückgängig zu machen. Du kannst an einem Nachmittag mehrmals zwischen Mock und echtem Service hin- und herwechseln.
- Der Rest des Szenarios merkt es von selbst: die Entscheidung wird einmal getroffen und alle, die jenen Service aufrufen, wenden sie an.
Die Stubs werden im Mock Studio definiert: einen Aufruf mitschneiden und mit einem Klick in einen Stub verwandeln, das Antwortgerüst aus einem OpenAPI erzeugen, und Varianten pro Service verwalten —die glückliche Antwort, die mit 404, die langsame— mit Hot Reload, ohne irgendetwas neu zu starten.
Was ein Mock dir nicht geben wird
Das gehört hierher, denn genau hier geht Zeit verloren: wenn der Fehler, den du jagst, im echten Service lebt —ein Header, den das Gateway hinzufügt, ein Payload, den niemand dokumentiert hat, das Verhalten unter Last—, wird der Mock ihn per Definition nicht reproduzieren. Was du dann brauchst, ist die gemeinsame Umgebung zu erreichen, und wenn dein System zu groß für deine Maschine ist, erklärt der Telepresence-Vergleich den anderen Ansatz.
Die konkreten Schritte stehen in eine Abhängigkeit mocken, und wenn dich blockiert, dass zu viel hochgefahren werden muss, die Seite über nur einen Teil des Systems starten.
Häufige Fragen
Wann sollte ich einen Service mocken und wann nicht?
Mocke ihn, wenn seine Antwort nicht das ist, was du testest: du brauchst sie, damit dein Ablauf weitergeht, nicht um sie zu prüfen. Mocke ihn nicht, wenn du gerade prüfen willst, wie dein Code auf das reagiert, was jener Service wirklich zurückgibt —dort sagt dir ein Stub, alles sei in Ordnung, und das stimmt nicht—.
Lügt mich ein Mock nicht irgendwann an?
Er kann, und das ist sein echtes Risiko: der Stub friert einen Vertrag ein, der sich auf der anderen Seite weiter ändert. Man mildert das, indem man ihn aus dem OpenAPI des Service generiert statt von Hand, und indem man echte Aufrufe mitschneidet, wenn man ihn erreichen kann.
Wie wechsle ich zwischen echtem Service und Mock, ohne meine Repositories zu ändern?
Mit Aseptic ist es eine Entscheidung pro Abhängigkeit: du wählst lokal, Cloud oder Mock, und die URL wird beim Start umgeschrieben, als Konfiguration injiziert. Die Datei im Repository bleibt genau so, wie sie in git steht.
Muss ich den Stub von Hand schreiben?
Nicht zwingend. Man kann das Antwortgerüst aus einem OpenAPI erzeugen, oder einen echten Aufruf mitschneiden, das eine Mal, als du Zugang hattest, und ihn mit einem Klick in einen Stub verwandeln.