Bruno ist ein leichter, Git-nativer Open-Source-API-Client, dessen Design ihn schnell und einfach versionierbar macht. Aber es hinterlässt eine Lücke, die Teams schnell merken: Es gibt keine Möglichkeit, einen Endpunkt zu simulieren, der noch nicht existiert. Wenn Sie nach einer Alternative für einen Bruno Mock-Server gesucht haben, erklärt dieser Leitfaden, warum diese Lücke existiert, welche Workarounds verwendet werden und wie Sie einen Mock-Server direkt aus Ihrer OpenAPI-Spezifikation generieren können.
Die kurze Antwort vorab: Bruno hat keinen integrierten Mock-Server. Sie können Anfragen senden und Tests schreiben, aber Sie können keinen gefälschten Endpunkt bereitstellen, der Beispielantworten zurückgibt. Für das Mocking greifen Sie zu einem externen Tool oder erstellen einen Server selbst von Hand.
Warum Sie einen Mock-Server benötigen
Ein Mock-Server liefert realistische Antworten für Endpunkte, die noch nicht erstellt, nicht stabil oder schwer auf Abruf auszulösen sind. Das ermöglicht einiges:
- Parallele Entwicklung. Front-End- und mobile Teams entwickeln anhand des Vertrags, während das Backend noch in Arbeit ist. Niemand wartet.
- Fehlerpfad-Tests. Echte APIs geben Ihnen selten eine 429 oder 503, wenn Sie eine brauchen. Ein Mock gibt jeden Status, Header oder falsch formatierte Körper auf Befehl zurück.
- Demos und Prototypen. Zeigen Sie einen funktionierenden Workflow ohne Live-Backend, Datenbank oder Anmeldeinformationen.
- Stabile CI. Tests, die einen Mock treffen, schlagen nicht fehl, weil ein Staging-Server ausgefallen oder ratenbegrenzt ist.
Hier sind Fehlerfälle, bei denen ein Mock Ihnen hilft, gezielt zu testen, anstatt darauf zu warten, dass sie in der Produktion auftreten:
| Szenario | Was der Mock zurückgibt | Warum es sonst schwierig ist |
|---|---|---|
| Ratenbegrenzung erreicht | 429 + Retry-After Header |
Backend drosselt selten auf Anfrage |
| Serverausfall | 500 / 503 |
Man kann Staging nicht nur zum Testen unterbrechen |
| Langsame Antwort | Verzögerter Körper | Schwierig, reale Latenz zu reproduzieren |
| Leeres Ergebnis | 200 mit [] |
Hängt vom spezifischen Datenzustand ab |
| Fehlerhaftes Payload | Körper, dem ein erforderliches Feld fehlt | Backend-Validierung verhindert dies normalerweise |
Hat Bruno einen Mock-Server?
Nein. Bruno konzentriert sich auf das Senden von Anfragen, das Organisieren von Sammlungen als einfache Dateien und das Ausführen von Assertions. Es gibt keinen nativen Mock-Server und keine Einstellung, die eine gespeicherte Anfrage in einen Live-Stub verwandelt. Das ist eine bewusste Entscheidung im Umfang, keine Überwachung, aber es bedeutet, dass Mocking außerhalb des Tools stattfindet.
In der Praxis überbrücken Bruno-Benutzer die Lücke auf zwei Arten:
- Externe Mocking-Tools. Richten Sie einen separaten Dienst wie Mockoon, WireMock, Prism oder json-server ein, definieren Sie dort Antworten und verweisen Sie Bruno dann auf diese URL. Zwei Tools, zwei Wahrheitsquellen.
- Selbst erstellte Server. Schreiben Sie eine kleine Express-, Flask- oder FastAPI-App, die vorbereitete JSON-Daten zurückgibt. Schnell für einen Endpunkt, mühsam zu pflegen bei einer wachsenden API.
Beides funktioniert. Beides fügt bewegliche Teile hinzu, die außerhalb Ihrer Sammlung existieren.
Die Kosten von nachträglich hinzugefügtem Mocking
Eine separate Mock-Schicht an Bruno anzufügen, ist praktikabel, aber die Kosten zeigen sich im Laufe der Zeit:
- Abweichung. Ihre Spezifikation, Ihre Bruno-Anfragen und Ihre Mock-Definitionen existieren an drei Stellen. Ändern Sie einen Endpunkt, und Sie müssen alle drei aktualisieren, oder eine davon wird stillschweigend veraltet.
- Einrichtungsaufwand. Jeder neue Teamkollege installiert und konfiguriert das Mock-Tool, bevor er etwas lokal ausführen kann.
- Manuelles Schreiben von Antworten. Bei selbst erstellten Servern müssen Beispiel-Payloads für jedes Feld und jeden Statuscode manuell geschrieben werden.
- Keine realistischen Daten. Statische Stubs geben immer denselben
"name": "string"zurück, was Fehler verbirgt, die nur bei unterschiedlichen Eingaben auftreten.
Nichts davon ist fatal. Aber es ist Reibung, die sich mit dem Wachstum der API verstärkt. Eine genauere Betrachtung, wo diese Lücken entstehen, finden Sie in unserer Aufschlüsselung der Bruno-Alternative als All-in-One-API-Plattform.
Stattdessen einen Mock-Server aus Ihrer OpenAPI-Spezifikation generieren
Der sauberere Weg ist, den Mock aus dem Vertrag abzuleiten, den Sie bereits pflegen. Apidog tut dies: Importieren oder schreiben Sie eine OpenAPI-Spezifikation, und es generiert einen funktionierenden Mock-Server aus denselben Definitionen, die Sie für Design, Tests und Dokumentation verwenden. Eine einzige Quelle der Wahrheit, nicht drei.
Einige Dinge unterscheiden dies von nachträglich hinzugefügten Tools:
- Smarter Mock aus der Spezifikation. Apidog liest Feldnamen und -typen und gibt plausible Daten zurück, sodass ein
email-Feld wie eine E-Mail und eincreated_at-Feld wie ein Datum aussieht, ohne dass Regeln geschrieben werden müssen. - Dynamische Antworten. Antworten werden bei jeder Anfrage aus Ihrem Schema generiert, sodass Sie unterschiedliche Daten anstelle eines festen Beispiels erhalten. Sie können bei Bedarf bedingte Regeln hinzufügen, wenn Sie einen bestimmten Fall benötigen.
- No-Code-Setup. Sie schreiben oder hosten keinen separaten Server. Definieren Sie den Endpunkt in der Spezifikation und die Mock-URL ist bereit.
- Bleibt synchron. Aktualisieren Sie die Spezifikation, und der Mock aktualisiert sich ebenfalls, da sie eine Definition teilen.
Da der Mock, die Anfragelibrary und die Dokumentation aus demselben Projekt stammen, gibt es keine dritte Stelle, die abgeglichen werden muss. Wenn Ihr Workflow Git-zentriert ist, bleibt die Spezifikation auch diff-fähig und überprüfbar, was gut zu einem Git-nativen API-Workflow passt. Weitere Informationen darüber, wo Mocking sich bewährt, finden Sie unter Anwendungsfälle für API-Mocking.
Kurzanleitung: Von der Spezifikation zur Mock-URL
Hier ist die Kurzversion, wie Sie einen Mock aus einer bestehenden Spezifikation erstellen:
- Importieren Sie Ihre Spezifikation. Importieren Sie Ihre OpenAPI- (oder Swagger-) Datei oder verweisen Sie Apidog auf die Spezifikations-URL. Bestehende Endpunkte und Schemata werden unverändert übernommen.
- Öffnen Sie einen Endpunkt. Jeder importierte Endpunkt hat bereits sein Schema, sodass der Mock alles hat, was er braucht.
- Holen Sie sich die Mock-URL. Apidog stellt automatisch einen lokalen und einen Cloud-Mock-Endpunkt bereit. Kein Server muss bereitgestellt werden.
- Senden Sie eine Anfrage. Greifen Sie auf die Mock-URL zu und Sie erhalten ein Schema-förmiges JSON zurück, das aus der Spezifikation generiert wurde.
- Antworten anpassen (optional). Fügen Sie Regeln für bestimmte Statuscodes oder Grenzfälle hinzu, wie z.B.
429, wenn Sie einen bestimmten Pfad testen müssen.
Sie richten Ihr Front-End, Ihren mobilen Build oder Ihre Testsuite auf die Mock-URL aus und fahren fort, während das Backend aufholt.
Wann die Workarounds ausreichen
Fairerweise braucht man nicht immer einen spezifikationsgesteuerten Mock. Bleiben Sie bei Bruno plus einem leichten externen Tool, wenn:
- Sie nur ein oder zwei Endpunkte für einen schnellen lokalen Test simulieren müssen.
- Ihr Team gerne die dateibasierten Sammlungen von Bruno pflegt und keine Tools wechseln möchte.
- Ein statischer Stub ausreicht, weil Sie keine unterschiedlichen Daten oder viele Fehlerpfade testen.
- Sie bereits Mockoon, WireMock oder Prism verwenden und die zusätzliche Wahrheitsquelle Sie nicht verlangsamt.
Der Kompromiss ist real: Der leichte Weg bewahrt die Einfachheit von Bruno, aber Sie müssen Mocks separat pflegen. Der spezifikationsgesteuerte Weg beseitigt diese Abweichung auf Kosten der Einführung einer breiteren Plattform. Wählen Sie basierend darauf, wie stark Ihre API wächst.
FAQ
Hat Bruno einen integrierten Mock-Server?
Nein. Bruno ist ein API-Client zum Senden von Anfragen und Ausführen von Tests. Er verfügt über keinen nativen Mock-Server, daher verwenden Sie zum Mocken von Endpunkten ein externes Tool oder schreiben Ihren eigenen Stub-Server und verweisen Bruno darauf.
Was ist der einfachste Weg, Mocking zu einem Bruno-ähnlichen Workflow hinzuzufügen?
Generieren Sie den Mock aus Ihrer OpenAPI-Spezifikation, anstatt ihn separat zu definieren. Tools wie Apidog lesen die Spezifikation und erzeugen eine fertige Mock-URL, sodass Sie eine einzige Quelle der Wahrheit für Design, Mocking, Tests und Dokumentation beibehalten, anstatt Mock-Definitionen an einer zweiten Stelle zu pflegen.
Kann ich Bruno weiterhin verwenden und einfach einen Mock-Server daneben hinzufügen?
Ja. Führen Sie ein externes Mock-Tool wie Mockoon, WireMock oder Prism aus, definieren Sie dort Antworten und verweisen Sie Bruno auf diese URL. Das funktioniert, aber Ihre Spezifikation, Anfragen und Mock-Daten leben an separaten Orten und können auseinanderdriften, was der Hauptgrund ist, warum Teams konsolidieren.
Wenn die Pflege einer separaten Mock-Schicht mehr kostet, als sie spart, lohnt es sich, einen spezifikationsgesteuerten Mock auszuprobieren. Importieren Sie Ihre OpenAPI-Datei in Apidog und Sie haben in wenigen Minuten eine funktionierende Mock-URL, ohne einen zusätzlichen Server hosten zu müssen.