Portable Simulationen

Eine portable Simulation ist die gepackte Form eines Mocks: die ganze Simulation - Specs, statische Endpunkte, Konfiguration, Kontexte - als einfache Dateien. Portabel heißt, das Paket reist: Dieselben Dateien laufen auf deinem Laptop, in Docker, in der CI und gehostet auf der Plattform, und nichts hindert sie daran, an all diesen Orten gleichzeitig zu laufen.

Ein Befehl

Mit installierter CLI wird jede OpenAPI-Spec zu einem laufenden Mock:

mockzilla petstore.yml

Der Server startet auf Port 2200, mit dem API-Explorer an seiner Wurzel, derselben durchsuchbaren Oberfläche, die eine gehostete Simulation ausliefert.

Er nimmt mehr als eine Datei:

mockzilla https://petstore3.swagger.io/api/v3/openapi.json   # eine Spec per URL
mockzilla ./                                                 # ein Ordner mit Specs oder Services
mockzilla petstore.mockz                                     # eine verpackte Simulation

Siehe CLI installieren dafür, wie mockzilla auf deine Maschine kommt, und Eine Simulation lokal ausführen für den .mockz-Weg: Jede deployte Simulation reicht dir dort ihr Paket, gehostet und lokal bleiben also derselbe Mock.

Der Ordner ist die Simulation

Zeigst du die Engine auf ein Verzeichnis, liest sie eine von drei Formen, von Wegwerf bis Vollprojekt:

• Ein Haufen Specs: Lege Spec-Dateien in einen Ordner, und jede wird ein Service, benannt nach ihrem Dateinamen. Mehr braucht es nicht.
• Ein Service-Ordner: eine Spec plus optional config.yml (Latenz, Fehler, Upstream, Mount), context.yml (Werte für generierte Daten) und statische Endpunktdateien.
• Ein services/-Baum: ein Ordner pro Service, jeder mit demselben Layout - die Form, die die GitHub Action deployt und das Template mitbringt.

Statische Endpunkte folgen der Konvention aus der App: Pfadsegmente als Ordner, die Methode als letzter Ordner, index.<ext> als Body.

Siehe Endpunkte und statische Antworten.

Bearbeiten und zusehen

Der Server beobachtet deine Dateien. Speichere eine Spec, eine Konfiguration, einen Kontext oder einen statischen Endpunkt, und der betroffene Service wird live getauscht, ohne Neustart: links auf dem Bildschirm das YAML bearbeiten, rechts das neue Verhalten curlen.

Dieselben Einstellungen, als Dateien

Alles, was eine gehostete Simulation in der App konfiguriert, konfiguriert eine portable in der config.yml je Service: Latenz und Fehlerinjektion, ein Upstream mit Mock-Fallback, Caching, Verlauf, Replay. Die Optionen und ihre Bedeutung decken sich eins zu eins mit der Seite Service-Einstellungen.

Die vollständige Flag- und Konfigurationsreferenz liegt bei der Engine: Portable-Modus-Dokumentation.

Ein Paket, viele Orte

Der Sinn des Pakets ist, es überall zugleich laufen zu lassen, aus einem Satz Dateien:

• Auf deiner Maschine beim Entwickeln, Hot Reload inklusive.
• In der CI: Ein Pipeline-Schritt startet seine eigene Kopie, die Tests laufen dagegen, und sie stirbt mit dem Job.
• Gehostet: Derselbe Ordner deployt über die GitHub Action, die geteilte URL des Teams liefert also genau, was das Repo hält.
• Offline oder abgeschottet, wenn es sein muss: Sind Binary und Dateien da, braucht es nichts weiter.

Weil jede Kopie dieselben Dateien liest, ist das Repository die eine Quelle der Wahrheit. Jede Kopie holt sich einen Merge in ihrem eigenen Rhythmus: die gehostete URL mit dem Push danach, eine Pipeline beim nächsten Lauf, ein Laptop beim nächsten Pull.