Bereich Mocks

Der Bereich Mocks ist, wo Sie die simulierten Antworten definieren, die Aseptic liefert, wenn eine Abhängigkeit als Mock aufgelöst wird. Er erlaubt Ihnen, ohne Cloud-Verbindung und ohne den Core zu starten, den Ihr Micro aufruft, zu arbeiten.

Sie müssen nichts starten, um Mocks zu bearbeiten: Der Katalog lebt auf der Festplatte (.aseptic/mocks/<Dienst>.json) und wird mit Hot-Reload geliefert, sodass eine Änderung sofort angewendet wird, selbst wenn das Szenario läuft.

Der Baum: Dienste → Endpoints

Die Seite zeigt einen Baum von Diensten (den mockbaren Cores) und, in jedem, seine Endpoints in einer flachen Liste, alphabetisch nach Pfad sortiert. Jede Zeile zeigt den vollständigen Pfad relativ zur Basis des Dienstes, sodass zwei Endpoints mit gleichem Ende (/orders/lines und /invoices/lines) nicht verwechselt werden. Um einen großen Katalog einzugrenzen, filtert die Suche der Seite nach Dienstname oder Pfad.

Ein Dienst ist mockbar, wenn er eine Abhängigkeit eines Micros ist (oder wenn Sie seine Datei in .aseptic/mocks erstellen). Sie können die Dienste ein- oder ausblenden, die noch keine Stubs haben.

Einen Stub erstellen

Drücken Sie Neuer Stub (oder das Menü „⋮“) und wählen Sie den Zieldienst —einen aus dem Katalog oder einen neuen, der beim Speichern erstellt wird—. Ein Endpoint wird definiert mit:

Methode und Pfad (relativ zum Basispfad des Dienstes).
Einer oder mehreren Antwort-Varianten.

Es gibt zwei Wege, den Body zu füllen:

Aus OpenAPI: Wenn der Dienst eine OpenAPI-Spezifikation deklariert (im Manifest des Micros oder aus seiner Cloud-URL abgeleitet), wählen Sie die Operation und Aseptic generiert eine Vorlage des Bodys.
Manuell: Wenn es kein OpenAPI gibt, schreiben Sie den JSON-Body von Hand.

Das OpenAPI-Symbol neben dem Dienst öffnet die Spezifikation in einer eigenen Ansicht, mit durchsuchbaren Operationen, statt Ihnen die rohe Datei vorzusetzen.

Gruppen und Dienste

Jeder Dienst im Baum hat seine eigene Ansicht („Dienst bearbeiten“ in seinem Menü oder das Zahnrad im Editor eines Stubs). In einer selbst angelegten Gruppe —um Stubs zu sammeln, die zu keiner Abhängigkeit gehören, etwa alle /notice/...— bearbeitet man Name, Präfix, Basis-URL (die echte Adresse, für die das Präfix steht; dorthin geht der echte Aufruf) und OpenAPI. Bei einer Abhängigkeit bearbeitet man alles außer dem Namen, der ihre ID in den Manifesten ist: Präfix und Basis-URL werden im Manifest jedes Micros gespeichert, das sie deklariert, und Stubs unter dem bisherigen Präfix wandern zum neuen.

Beim Auswählen einer OpenAPI-Operation ermittelt Aseptic den Pfad, den der Client aufruft, auch wenn die Spezifikation ein anderes Präfix deklariert (ihre servers, den Context-Path, ein mit dem Dienstpräfix gemeinsamer Abschnitt). Hat diese Operation schon einen Stub, entsteht kein zweiter: Der vorhandene öffnet sich mit einer neuen Variante aus der OpenAPI.

Beim Anlegen eines Stubs kann man außer von einer OpenAPI-Operation auch von einem Aufruf ausgehen, der den Mock schon ohne Stub erreicht hat: Methode und Pfad werden übernommen.

Der Port des Mock-Servers und das OpenAPI-Token (als Authorization: Bearer beim Herunterladen geschützter Spezifikationen gesendet) liegen unter Mock-Einstellungen im „⋮“-Menü des Bereichs.

Varianten: die Arbeitseinheit

Ein Endpoint kann mehrere Varianten haben (zum Beispiel eine 200 und eine 500). Jede Variante hat ihre Bezeichnung, ihren Statuscode, ihren Body, ihre Header und eine optionale Latenz in Millisekunden, um Langsamkeit zu simulieren.

Die ausgewählte Variante klappt inline auf mit ihrem Body, ihren Headern und ihren Einstellungen zusammen. Die Variante, die geliefert wird, wird separat mit einem Umschalter markiert (sie ist unabhängig von der, die Sie bearbeiten): Es ist die Antwort, die Aseptic jedem zurückgibt, der diesen Endpoint aufruft.

Über dem Body gibt es drei Schaltflächen: Formatieren rückt ihn ein (und speichert diese Einrückung), Vorlage füllen erzeugt ihn aus dem OpenAPI, und Formatiert ansehen öffnet ihn in einem großen Betrachter, der nichts bearbeitet und dazu da ist, eine Antwort zu lesen, die nicht in den Kasten passt.

Sie können eine Variante duplizieren, um von einer ähnlichen auszugehen. Einen Endpoint, der nicht mehr geliefert werden soll, löschen Sie über sein Menü.

Bodys jeder Art: Bilder, PDFs, Dateien

Über dem Body jeder Variante wählst du Text, Ohne Body, Datei oder Stream:

Text: mit einer Formatauswahl —JSON, Klartext, HTML, XML, JavaScript, CSS, CSV, YAML, Markdown oder Formular—, die den ausgelieferten Content-Type setzt und jedem Format seine Hervorhebung und sein Formatieren gibt (ein Formular wird zu a=1&b=2 kompaktiert). Ein von Hand in den Einstellungen der Variante eingetragener Typ landet in seiner Familie (application/problem+json ist JSON).
Datei: ein Bild, ein PDF, ein Zip, eine Audiodatei… alles. Klicke auf Datei wählen oder lege sie darauf ab, und sie wird Byte für Byte ausgeliefert. Bei einem kleinen Bild siehst du eine Vorschau.
Ohne Body: nur Statuscode und Header, für ein 204 oder 304; es wird kein Content-Type erfunden.
Stream: die Antwort kommt in Fragmenten, jedes nach seiner Pause, um einen Client zu testen, der schon beim Empfang anzeigt oder zählt. Du wählst, wie jedes Fragment geschrieben wird: SSE-Events (text/event-stream, mit optionalem Event-Namen und ID), NDJSON (ein JSON pro Zeile) oder Text in Fragmenten.

Die Größe entscheidet, wo sie liegt: bis 256 KB im Katalog, reist also mit ihm; größere Dateien werden nach .aseptic/mocks/files/<dienst>/ kopiert und die Variante verweist darauf. Ohne Content-Type wird er aus der Endung abgeleitet (.png → image/png, .pdf → application/pdf); weitere Header —Content-Disposition für einen Download, Cache-Control…— kommen wie gewohnt unter Header. Beim Exportieren eines Dienstes oder Szenarios werden die Dateien eingebettet, das Geteilte hängt also nicht von diesem Ordner ab.

Regeln: nach der Anfrage antworten

Über den Varianten gibt es einen Block Regeln. Jede Regel sagt »wenn diese Bedingungen zutreffen, liefere diese Variante«, und sie werden der Reihe nach ausgewertet: die erste passende gewinnt. Passt keine, wird die aktive Variante geliefert — ein Endpoint ohne Regeln verhält sich also genau wie vorher. Die letzte, feste Zeile des Blocks sagt genau das.

Eine Bedingung schaut auf ein Stück der Anfrage, ohne Syntax zum Lernen: Query oder Header über den Namen, oder Body über einen Punktpfad (bestellung.kunde.stufe; eine Zahl geht in eine Liste, bestellung.zeilen.0.sku). Verglichen wird mit ist gleich, ist ungleich, existiert oder existiert nicht. Alle Bedingungen einer Regel müssen zusammen zutreffen; für ein »oder« kommt eine zweite Regel dazu — dafür ist die geordnete Liste da. Die Reihenfolge ändern die Pfeile jeder Regel: eine Regel zu verschieben heißt, ihre Priorität zu ändern.

Eine Regel zeigt über die Bezeichnung auf eine Variante, nicht über ihre Position, damit das Umsortieren von Varianten nicht stillschweigend ändert, was geliefert wird. Darum dürfen in einem Endpoint mit Regeln zwei Varianten nicht gleich heißen. Wird eine Variante umbenannt, auf die eine Regel zeigte, wird die Regel markiert und nicht mehr geliefert, bis sie korrigiert ist.

Testen simuliert eine Anfrage an Ort und Stelle — Query, Header und Body — und sagt, welche Variante herauskäme und welche Regel sie gewählt hat. Das Szenario muss nicht laufen. Und wenn es läuft, markiert das Dock Mock-Aufrufe jeden Aufruf mit der Regel, die ihn entschieden hat, sodass sich zwei identische Aufrufe mit verschiedenen Antworten von selbst erklären.

Im Terminal ist es dasselbe: aseptic mock probe POST "/v1/bestellungen?stufe=premium", mit -H 'X-Vip: 1' für Header und -d '{...}' für den Body.

Automatisches Speichern

Der Mock-Editor speichert von selbst, mit einer kleinen Verzögerung, während Sie tippen; Sie sehen einen „Gespeichert“-Indikator. Sicherungen:

Es werden nur gültige Zustände persistiert: Ein halb geschriebener JSON-Body bricht den gelieferten Mock nicht —der letzte gültige bleibt auf der Festplatte und der Fehler wird inline markiert—.
Ein neuer Stub wird nicht persistiert, bis er eine nutzbare Methode und einen nutzbaren Pfad hat.
Das Löschen ist immer explizit, mit Bestätigung.

Mock Studio: von einem echten Aufruf zu einem Stub

Wenn ein Szenario läuft und ein Micro einen Mock aufruft, der noch keine Antwort hat, erscheint dieser Aufruf im Dock Mock-Aufrufe. Von dort können Sie mit einem Klick einen Stub erstellen aus dem beobachteten Aufruf: Sie gelangen direkt zum Endpoint, den Sie vervollständigen wollen, ohne ihn zu suchen. Sie können auch testen, was der Mock antworten würde, ohne etwas zu starten.

Echter Aufruf: die Antwort des Dienstes aufzeichnen

Manchmal willst du den Rumpf nicht erfinden, sondern den, den der echte Dienst zurückgibt. Jeder Endpoint hat einen Schalter Echter Aufruf. Solange er aktiv ist, bedient dieser Endpoint seine Variante nicht mehr: die Anfrage geht an den echten Dienst, seine Antwort wird unverändert an den Aufrufer zurückgegeben und als Variante «Real» mit ihrem Statuscode aufgezeichnet, die aktiv wird. Nach dem Ausschalten antwortet der Mock mit dem, was der Dienst zuletzt gesagt hat, ohne erneut nach außen zu gehen.

Wohin es ruft: an den Microservice des Szenarios, wenn er läuft, sonst an die Cloud-URL der Abhängigkeit. Das «i»-Symbol des Schalters nennt das genaue Ziel; hat der Dienst keines, bleibt der Schalter aus und erklärt warum.
Verben, die Daten ändern: das Einschalten für ein POST, PUT oder DELETE verlangt eine Bestätigung und nennt das Ziel. Es ist nicht verboten —die Antwort einer Anlage aufzuzeichnen ist ein legitimer Fall—, aber es wird dort wirklich ausgeführt.
Eine Variante pro Statuscode: Real 200, Real 404… Tausend Aufrufe erzeugen keine tausend Varianten; die zum eingetroffenen Code wird aufgefrischt.
Was kein Text ist (ein Bild, ein PDF), wird als Datei der Variante aufgezeichnet; was größer als 1 MB ist, wird bedient, aber nicht aufgezeichnet.

Endpoints im Aufzeichnungsmodus tragen im Baum die Markierung real, damit dir keiner unbemerkt nach außen telefoniert.

Importieren und exportieren

Mit den Import/Export-Symbolen des Panels:

Exportieren Sie die Endpoints eines Dienstes (oder mehrerer) in eine JSON-Datei.
Importieren Sie Ihr eigenes JSON oder eine Postman-Collection (ihre Ordner werden auf Dienste abgebildet).

Nützlich, um einen Mock-Katalog zu teilen oder ihn szenarioübergreifend wiederzuverwenden.

Dasselbe vom CLI

All das existiert auch im CLI: aseptic mock services, mock catalog, mock save, mock set-active, mock skeleton, mock from-call, mock probe, mock capture, mock put-file, mock import / export. Siehe die CLI-Referenz.