Bruno CLI vs Apidog CLI: API-Tests im CI ausführen

Ihre API-Tests bestehen auf Ihrem Laptop. Die eigentliche Frage ist, ob sie bei jeder Pull-Anfrage, jedem Merge, jedem nächtlichen Build ausgeführt werden, ohne dass ein Mensch etwas anklickt. Diese Aufgabe gehört einem Kommandozeilen-Runner. Er nimmt die von Ihnen bereits erstellten Tests und führt sie kopflos in Ihrer Pipeline aus, beendet sich mit einem sauberen Statuscode und schreibt einen Bericht, den Ihr CI-Dashboard lesen kann.

Zwei Runner tauchen ständig auf, wenn Teams dies einrichten: die Bruno CLI und die Apidog CLI. Sie lösen dasselbe Problem von unterschiedlichen Ausgangspunkten aus. Bruno ist ein Git-nativer, Offline-First, Open-Source API-Client, und seine CLI führt die .bru-Dateien aus, die in Ihrem Repository liegen. Apidog ist eine All-in-One API-Plattform, und seine CLI führt die visuellen Testszenarien aus, die Sie in der App erstellen. Beide lassen sich in GitHub Actions, GitLab CI, Jenkins und alles andere mit Node.js integrieren. Beide lassen den Build fehlschlagen, wenn ein Test fehlschlägt. Die Unterschiede zeigen sich darin, wie Sie Tests erstellen, wie Sie sich authentifizieren und wie die Testdefinition in die CI gelangt.

Dies ist ein ehrlicher Vergleich der beiden auf Kommandoebene. Keine Scheinargumente. Bruno macht einige Dinge wirklich gut, und Sie werden genau sehen, wo jeder Runner passt, bevor Sie einen in Ihre Pipeline integrieren.

Kurz gesagt

• Bruno CLI (@usebruno/cli, Binärdatei bru) führt .bru-Dateien direkt aus einem Ordner in Ihrem Git-Repository aus. Sie ist Open Source, offline und benötigt kein Konto oder Token. Sie richten sie auf ein Verzeichnis aus, und sie führt jede Anfrage und Assertion aus, die sie findet.
• Apidog CLI (apidog-cli, Binärdatei apidog) führt die Testszenarien aus, die Sie in der Apidog-App entwerfen, abgerufen über ID mithilfe eines Zugriffstokens. Sie schreiben Tests nicht als Code neu; das visuelle Szenario ist der Test, und die CLI führt ihn kopflos aus.
• Beide geben JUnit-, JSON- und HTML-Berichte aus, und beide lassen den Build bei einem fehlgeschlagenen Test fehlschlagen. JUnit XML ist in beiden Fällen das, was in CI-Dashboards integriert wird.
• Wählen Sie Bruno, wenn Sie alles im Repository haben möchten, keine Konten und volle Offline-Kontrolle über reine Text-Testdateien.
• Wählen Sie Apidog, wenn Sie visuelle Erstellung, Szenarienverkettung, Umgebungsverwaltung und datengesteuerte Ausführungen wünschen, ohne Testcode manuell pflegen zu müssen.

Das eigentliche Problem: Tests, die existieren, aber nie ausgeführt werden

Ein Test, den Sie manuell ausführen, ist ein Test, der verrottet. Jemand hat ihn erstellt, er lief einmal erfolgreich, und dann blieb er unberührt, während sich die API darunter änderte. Die Lösung sind nicht mehr Tests. Es sind Tests, die bei jeder Änderung automatisch ausgeführt werden, mit einem Bestanden-/Fehlgeschlagen-Signal, auf das die Pipeline reagieren kann.

Ein CLI-Runner schließt diese Lücke. Er benötigt drei Dinge, um in CI nützlich zu sein: Er muss ohne GUI ausgeführt werden, er muss bei einem Fehler einen Exit-Code ungleich Null zurückgeben, damit der Build rot wird, und er muss einen maschinenlesbaren Bericht schreiben, damit Prüfer sehen, was kaputt ist. Bruno und Apidog erfüllen beide diese Anforderungen. Wo sie sich unterscheiden, liegt vor dem Ausführungsbefehl, nämlich wie der Test geschrieben wurde und wo er lebt.

Wenn Sie CI von Grund auf neu einrichten, lohnt es sich, die umfassenderen Muster zur Automatisierung von API-Tests in CI/CD parallel zu diesem Vergleich zu lesen. Hier konzentrieren wir uns auf die beiden Runner selbst.

Was die Bruno CLI gut macht

Brunos gesamtes Design ist Git-nativ. Jede Anfrage, Umgebung und Assertion ist eine reine Text-.bru-Datei auf der Festplatte, in Ihrem Repository, versioniert wie jede andere Quelldatei. Dieses Modell hat echte Vorteile, und es lohnt sich, sie vor jedem Vergleich klar darzulegen.

Ihre Tests leben mit Ihrem Code. Eine Pull-Anfrage, die einen Endpunkt ändert, kann den Test für diesen Endpunkt im selben Diff ändern, von derselben Person überprüft. Es gibt kein separates System zur Synchronisierung, keine Cloud-Kopie, die vom Inhalt des Repos abweichen kann. Diffs sind lesbar, weil das Format Text ist. Sie können Ihre Tests mit denselben Tools durchsuchen, die Sie für Code verwenden, sie umgestalten und Merge-Konflikte in einem Editor lösen.

Sie ist auch Open Source und offline. Die CLI läuft vollständig auf Ihrem Rechner oder Ihrem CI-Runner ohne Konto, Anmeldung und Token. Für Teams mit strengen Datenhandhabungsregeln oder luftdichten Umgebungen ist das wichtig. Brunos kostenpflichtige Stufe, Bruno Ultimate, fügt Teamfunktionen wie SSO und SCIM, Secret-Manager-Integrationen und Audit-Funktionen hinzu, sodass das Projekt nicht nur ein Hobby-Tool ist. Aber der Kernclient und die CLI sind kostenlos und eigenständig, und das ist eine legitime Stärke.

Die Installation erfolgt mit einem Befehl:

npm install -g @usebruno/cli

Die Binärdatei ist bru. Sie führen eine Sammlung aus, indem Sie sie auf den Ordner zeigen, der Ihre .bru-Dateien enthält:

bru run --env staging

Wenn Sie aus dem Sammlungsverzeichnis ausgeführt werden, führt bru run die dort gefundenen Anfragen aus. Fügen Sie -r hinzu, um Unterordner rekursiv zu durchsuchen, damit verschachtelte Anfragen erfasst werden:

bru run -r --env staging

Das ist der Kernzyklus. Keine IDs, kein Token, kein Remote-Abruf. Die Dateien im Ordner sind die Tests, und die CLI führt sie aus.

Wir haben die umfassendere Bruno-Geschichte in was Bruno als Git-nativen API-Client auszeichnet und wo seine Einschränkungen für größere Teams auftreten behandelt. Speziell für CI sind die oben genannten Stärken die entscheidenden.

Was die Apidog CLI gut macht

Apidog geht einen anderen Weg zur selben Pipeline. Sie erstellen Tests visuell in der Apidog-App: verketten Anfragen zu einem Szenario, fügen Zusicherungen hinzu, ziehen einen Wert aus einer Antwort in die nächste Anfrage und wiederholen den gesamten Vorgang über eine Datendatei. Die CLI ist der kopflose Ausführer für diese Szenarien. Sie hat kein eigenes Dateiformat. Sie ruft das Szenario, das Sie per ID benennen, aus Ihrem Apidog-Projekt ab und führt es genau so aus, wie es die App tun würde.

Der Vorteil ist, dass niemand zwei Repräsentationen desselben Tests pflegen muss. Das Szenario im Projekt ist der Test. Sie erstellen es in einem visuellen Builder, der Anfragenverkettung, Variablenextraktion und Zusicherungen handhabt, ohne dass Sie Skriptdateien schreiben und debuggen müssen. Dann führt die CLI dasselbe Szenario in CI aus. Der schnelle Erstellungszyklus und der Automatisierungszyklus verwenden eine einzige Quelle der Wahrheit.

Die Installation erfolgt mit einem npm-Befehl:

npm install -g apidog-cli

Die Binärdatei ist apidog. Eine typische Ausführung benennt ein Szenario per ID, wählt eine Umgebung aus und authentifiziert sich mit einem Zugriffstoken:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r html,junit

Sie tippen diese IDs nicht von Hand ein. Öffnen Sie das Testszenario, wechseln Sie zu dessen CI/CD-Tab, generieren Sie ein Zugriffstoken, und Apidog erstellt den vollständigen Befehl für Sie, wobei die Szenario-ID und die Umgebungs-ID bereits ausgefüllt sind. Sie kopieren ihn einmal, verschieben dann das Token in ein CI-Secret und referenzieren es als $APIDOG_ACCESS_TOKEN. Die vollständige Flag-Referenz finden Sie im Apidog CLI Complete Guide, wenn Sie alle Optionen an einem Ort haben möchten.

Das tokenbasierte Modell ist der deutlichste Unterschied zu Bruno. Apidog führt Tests aus, die in einem Projekt gespeichert sind, auf das die CLI authentifiziert über das Netzwerk zugreift. Bruno führt Tests aus, die als Dateien gespeichert sind, die die CLI von der Festplatte liest. Keines ist falsch; sie passen zu unterschiedlichen Team-Setups.

Nebeneinander

Zwei Dinge fallen auf. Erstens decken beide Runner dieselben CI-Grundlagen ab: Umgebungsselektion, datengesteuerte Iteration, die drei wichtigen Berichtsformate und einen Exit-Code ungleich Null bei Fehler. Zweitens geht es bei der Aufteilung darum, wo der Test lebt und wie Sie ihn geschrieben haben, nicht um die reine Leistungsfähigkeit. Bruno speichert den Test als Text im Repository. Apidog speichert ihn als visuelles Szenario im Projekt und führt ihn per Referenz aus.

Reporter und Exit-Codes: Die Teile, die CI tatsächlich liest

Ein Runner verdient seinen Platz in einer Pipeline durch zwei Verhaltensweisen: den Bericht, den er schreibt, und den Exit-Code, den er zurückgibt. Wenn diese stimmen, ist der Rest nur noch Verdrahtung.

Bruno schreibt Berichte mit formatspezifischen Flags. Sie geben für jedes gewünschte Format einen Pfad an:

bru run -r --env staging \
  --reporter-junit ./results/junit.xml \
  --reporter-html ./results/report.html \
  --reporter-json ./results/report.json

Das JUnit XML ist das, was Ihr CI-Dashboard in einen Bestanden-/Fehlgeschlagen-Baum parst. Der HTML-Bericht ist ein durchsuchbares Artefakt. Brunos --bail stoppt die Ausführung nach der ersten fehlgeschlagenen Anfrage, dem ersten Test oder der ersten Assertion, was bei einem Smoke-Test schnelles Feedback ermöglicht. Ohne --bail wird alles ausgeführt und alle Fehler auf einmal gemeldet.

Apidog verwendet ein einziges -r-Flag mit einer kommagetrennten Liste und schreibt alles in ein Ausgabeverzeichnis:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 \
  -r html,junit --out-dir ./apidog-reports

Sein --on-error-Flag steuert das Verhalten mitten im Szenario: end stoppt beim ersten Fehler (der Standard), continue führt jeden Schritt aus, sodass Sie alle Fehler in einem Bericht sammeln, und ignore überspringt einen bekanntermaßen fehlerhaften Schritt. In jedem Fall endet die Ausführung mit einem Wert ungleich Null, wenn etwas fehlgeschlagen ist.

Der Exit-Code-Vertrag ist auf beiden Seiten gleich und der tragende Teil. Wenn eine Assertion fehlschlägt, beendet sich der Runner mit einem Code ungleich Null. CI liest diesen Code, markiert den Schritt als fehlgeschlagen, lässt den Job fehlschlagen und blockiert den Merge oder das Deployment. Sie konfigurieren nichts Zusätzliches. Die einzige Falle, die für beide identisch ist, ist das Verschlucken des Exit-Codes: Wenn Sie die Ausführung in eine Shell-Pipeline packen oder || true anhängen, wird der Exit-Code ungleich Null verschluckt und das Gate funktioniert stillschweigend nicht mehr. Tun Sie das nicht.

Bruno CLI in GitHub Actions

Da die .bru-Dateien bereits im Repository sind, ist der Workflow kurz. Code auschecken, CLI installieren, Sammlung ausführen, Bericht hochladen.

name: API tests

on:
  pull_request:
    branches: [main]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Bruno CLI
        run: npm install -g @usebruno/cli

      - name: Run API tests
        working-directory: ./api-tests
        run: bru run -r --env staging --reporter-junit ./results/junit.xml

      - name: Upload report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: bruno-report
          path: ./api-tests/results

Das working-directory zeigt auf den Ordner, der Ihre Sammlung enthält. if: always() sorgt dafür, dass der Bericht-Upload auch dann ausgeführt wird, wenn Tests fehlschlagen, was genau dann der Fall ist, wenn Sie ihn lesen möchten. Es wird kein Secret benötigt, da sich nichts bei einem Remote-Dienst authentifiziert.

Apidog CLI in GitHub Actions

Der Apidog-Workflow ist strukturell derselbe, mit einer Ergänzung: Der Zugriffstoken stammt aus Repository-Secrets, und Sie wählen das Szenario anhand der ID anstelle des Ordnerpfads aus.

name: API tests

on:
  pull_request:
    branches: [main]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Apidog CLI
        run: npm install -g apidog-cli

      - name: Run API test scenario
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t 605067 \
            -e 1629989 \
            -r html,junit \
            --out-dir ./apidog-reports
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

      - name: Upload report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: apidog-report
          path: ./apidog-reports

Beachten Sie die Symmetrie. Gleicher Checkout, gleiche Node-Einrichtung, gleiche Install-dann-Ausführen-Form, gleicher Immer-Upload. Die einzigen wirklichen Unterschiede sind das als Secret verdrahtete Token und das per ID ausgewählte Szenario. Wenn Sie dies auch mit GitLab CI- und Jenkins-Varianten erweitert haben möchten, überträgt der Apidog CLI Complete Guide dasselbe Muster über alle Runner hinweg.

Wie man wählt

Die Entscheidung hängt selten davon ab, welcher Runner „besser“ ist. Sie hängt davon ab, wie Ihr Team Tests erstellen und speichern möchte.

Wählen Sie Bruno, wenn das Repository die Quelle der Wahrheit ist. Wenn Sie jeden Test als reine Textdatei neben dem Code haben möchten, den er abdeckt, in derselben Pull-Anfrage überprüft, ohne Konto und ohne Netzwerkaufruf zur Laufzeit, passt Bruno genau zu diesem Modell. Es ist die natürliche Wahl für Teams, die Tests als Code behandeln, Offline- und Open-Source-Tools schätzen und sich mit der direkten Bearbeitung von .bru-Dateien wohlfühlen. Bruno Ultimate fügt SSO, SCIM, Secret-Manager-Integrationen und Audit-Funktionen hinzu, falls Sie später die Team- und Governance-Ebene benötigen, sodass das Wachstum damit eine Option und keine Barriere ist.

Wählen Sie Apidog, wenn die Erstellungsgeschwindigkeit und ein integrierter Workflow wichtiger sind als die Kontrolle auf Dateiebene. Wenn Sie lieber ein Testszenario visuell erstellen, Anfragen verketten, Variablen extrahieren und dasselbe Szenario über verschiedene Umgebungen hinweg ausführen möchten, ohne Testcode manuell zu schreiben und zu debuggen, eliminiert Apidogs Modell diese Reibung. Entwurf, Debugging, Mocking und Tests finden in einem Arbeitsbereich statt, und die CLI führt genau das Szenario aus, das Sie erstellt haben. Für Teams, die von einem Postman-Setup kommen, passt das mentale Modell sauber, und der Migrationspfad ist einer, den Apidog als Postman-Alternative für API-Tests abdeckt.

Es gibt auch eine Antwort für beide Tools. Einige Teams behalten Brunos Git-native Dateien für Low-Level-Anfrageprüfungen und verwenden Apidog für größere verkettete Szenarien und umgebungsintensive Regressionstests. Die beiden CLIs koexistieren problemlos in einer Pipeline; es sind separate Schritte mit separaten Exit-Codes.

Wenn Sie sich allgemeiner zwischen den Plattformen entscheiden, nicht nur den CLIs, deckt der Apidog vs. Bruno Vergleich Design, Mocking und Zusammenarbeit jenseits der Kommandozeile ab. Um Ihr erstes automatisiertes Szenario einzurichten und es noch am selben Nachmittag vom Terminal aus auszuführen, laden Sie Apidog herunter und kopieren Sie den generierten Befehl aus dem CI/CD-Tab eines beliebigen Szenarios.

Häufig gestellte Fragen

Ist die Bruno CLI kostenlos?

Ja. Die Bruno CLI ist Open Source und wird als @usebruno/cli npm-Paket ausgeliefert. Sie läuft vollständig auf Ihrem Rechner oder CI-Runner ohne Konto oder Token. Bruno Ultimate ist eine separate kostenpflichtige Stufe, die Team- und Governance-Funktionen wie SSO, SCIM, Secret-Manager-Integrationen und Auditing hinzufügt, aber die CLI selbst ist kostenlos.

Ist die Apidog CLI kostenlos?

Die CLI ist ein kostenloses npm-Paket, apidog-cli. Sie führt die Testszenarien aus Ihrem Apidog-Projekt aus, sodass das, was Sie ausführen können, von Ihrem Apidog-Plan abhängt, aber der Kommandozeilen-Runner ist kein separates kostenpflichtiges Produkt.

Muss ich Tests für einen der Runner als Code schreiben?

Für Bruno sind Ihre Tests .bru-Dateien, die Sie manuell bearbeiten oder in der Bruno-App erstellen können, es gibt also ein Textformat, das Sie direkt bearbeiten werden. Für Apidog erstellen Sie Szenarien visuell in der App, und die CLI führt sie per ID aus, sodass Sie den Testcode nicht manuell pflegen müssen. Das ist der zentrale Unterschied in der Erstellung zwischen den beiden.

Lassen beide Runner den Build fehlschlagen, wenn ein Test fehlschlägt?

Ja. Beide beenden sich mit einem Code ungleich Null, wenn eine Assertion fehlschlägt, den CI liest, um den Schritt als fehlgeschlagen zu markieren und den Merge oder das Deployment zu blockieren. Brunos --bail stoppt beim ersten Fehler; Apidogs --on-error end tut dasselbe und ist der Standard. Vermeiden Sie es, eine der Ausführungen in || true zu packen, da dies den Exit-Code verschluckt und das Gate außer Kraft setzt.

Welches Berichtsformat sollte ich in CI verwenden?

Verwenden Sie JUnit XML für das maschinenlesbare Ergebnis, das Ihr CI-Dashboard in einen Bestanden-/Fehlgeschlagen-Baum parst, und fügen Sie HTML hinzu, wenn Sie ein durchsuchbares Artefakt wünschen. Bruno schreibt sie mit --reporter-junit und --reporter-html; Apidog verwendet -r html,junit. Beide unterstützen auch JSON für die benutzerdefinierte Nachbearbeitung.

Benötigt die Bruno CLI eine Internetverbindung oder ein Konto zur Ausführung?

Nein. Bruno führt die .bru-Dateien in Ihrem Repository lokal aus, ohne Anmeldung und ohne Remote-Abruf, was es für Offline- oder Air-Gapped CI geeignet macht. Apidogs CLI authentifiziert sich mit einem Zugriffstoken und ruft das Szenario aus Ihrem Projekt ab, benötigt also zur Laufzeit Netzwerkzugriff auf den Apidog-Dienst.

Kann ich eine der CLIs ohne globale Installation ausführen?

Ja, für beide. Verwenden Sie npx @usebruno/cli run ... oder npx apidog-cli run ..., um ohne persistente globale Installation auszuführen, was auf kurzlebigen CI-Runnern praktisch ist. Führen Sie bru run --help oder apidog run --help aus, um die genauen Optionen Ihrer installierten Version zu bestätigen.