Apidog CLI vs Postman CLI: Der bessere CI-Test-Runner

Ihre API-Tests bestehen, wenn Sie auf Ihrem Laptop auf „Ausführen“ klicken. Das beweist nichts. Der Test, der zählt, ist der, der bei jeder Pull-Anfrage, jedem Merge und jedem Nightly Build ausgelöst wird, ohne dass ein Mensch anwesend ist, um etwas anzuklicken. Die Aufgabe, Ihre Tests in diesen Kreislauf zu bringen, gehört zu einem Kommandozeilen-Runner. Er nimmt die Tests, die Sie bereits geschrieben haben, führt sie kopflos in Ihrer Pipeline aus, beendet sich mit einem Statuscode, den Ihre CI lesen kann, und schreibt einen Bericht, der auf dem Build-Dashboard angezeigt wird.

Zwei Runner tauchen immer wieder auf, wenn Teams dies einrichten: die Postman CLI und die Apidog CLI. Sie zielen auf dasselbe Ziel von unterschiedlichen Ausgangspunkten ab. Die Postman CLI führt die Sammlungen aus, die Sie in Postman erstellen. Die Apidog CLI führt die visuellen Testszenarien aus, die Sie in Apidog erstellen. Beide lassen sich in einem Schritt installieren, beide lassen sich in GitHub Actions, GitLab CI und Jenkins integrieren, und beide färben den Build rot, wenn ein Test fehlschlägt. Die wirklichen Unterschiede liegen vor dem Ausführungsbefehl: wie Sie Tests erstellen, wie Sie sich in CI authentifizieren und wo die Testdefinition tatsächlich lebt.

TL;DR

• Postman CLI (Binary `postman`) führt die in Ihrem Postman-Arbeitsbereich gespeicherten Sammlungen aus. Es basiert auf Newman, ist von Postman signiert und unterstützt und authentifiziert sich mit einem Postman-API-Schlüssel. Wenn Sie angemeldet sind, sendet es die Laufergebnisse automatisch an die Postman-Cloud zurück.
• Apidog CLI (`apidog-cli`, Binary `apidog`) führt die Testszenarien aus, die Sie visuell in Apidog entwerfen. Sie weisen es anhand einer ID mit einem Zugriffstoken auf ein Szenario hin, und es führt dieses Szenario kopflos ohne GUI aus.
• Beide erzeugen JUnit-, JSON-, HTML- und Terminalberichte. Beide lassen den Build bei einem fehlgeschlagenen Test fehlschlagen. JUnit XML ist in beiden Fällen das, was in ein CI-Dashboard integriert wird.
• Wählen Sie die **Postman CLI**, wenn Ihre Tests bereits in Postman-Sammlungen vorhanden sind und Ihr Team sich für die Postman-Cloud für Berichterstattung und Historie entschieden hat.
• Wählen Sie die **Apidog CLI**, wenn Sie visuelle Szenarioerstellung, Anforderungskettung, Umgebungsverwaltung und datengesteuerte Ausführungen aus einer einzigen Quelle der Wahrheit wünschen, mit vollständiger Kontrolle darüber, ob Berichte lokal bleiben oder in die Cloud gelangen.

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 geschrieben, er hat einmal bestanden, und dann blieb er unberührt, während die API sich darunter verschob. Drei Monate später ist der Test falsch und niemand hat es bemerkt, weil niemand ihn ausgeführt hat. Die Lösung ist nicht, mehr Tests zu schreiben. Es geht darum, die Tests, die Sie haben, bei jeder Änderung automatisch auszuführen, mit einem Bestanden- oder Fehlgeschlagen-Signal, auf das die Pipeline reagieren kann.

Ein CLI-Runner ist das Werkzeug, das diese Lücke schließt. Um einen Platz in CI zu erhalten, muss er drei Dinge tun. Er muss ohne GUI laufen, da Ihr CI-Runner keinen Bildschirm hat. Er muss mit einem Nicht-Null-Status beendet werden, wenn etwas fehlschlägt, damit der Build rot wird und ein fehlerhafter Merge blockiert wird. Und er muss einen maschinenlesbaren Bericht schreiben, damit der Prüfer sehen kann, was schiefgelaufen ist, ohne etwas lokal erneut ausführen zu müssen. Die Postman CLI und die Apidog CLI erfüllen diese Anforderungen sauber. Wo sie sich unterscheiden, ist alles, was vor dem `run`-Befehl passiert: wie der Test geschrieben wurde und wo er sich befindet, wenn die CI danach sucht.

Wenn Sie die automatisierte Testung von Grund auf neu einrichten, lohnt es sich, die umfassenderen Muster in der Automatisierung von API-Tests in CI/CD parallel zu diesem Artikel zu lesen. Hier liegt der Fokus weiterhin auf den beiden Runnern.

Was die Postman CLI gut kann

Zuerst ein Klärungspunkt, der viele Leute verwirrt: Die Postman CLI ist nicht Newman. Newman ist der ältere, quelloffene, npm-basierte Runner, den die Community seit Jahren verwendet. Die Postman CLI ist ein neueres Tool, das auf Newmans Grundlage aufbaut, aber von Postman dem Unternehmen signiert und offiziell unterstützt wird. Wenn Sie Newman verwendet haben, sind die beiden nicht austauschbar, und der Unterschied ist in CI wichtig. Wir haben diesen genauen Unterschied in Postman CLI vs Newman beschrieben, falls Sie sich zwischen den beiden Postman-seitigen Optionen entscheiden.

Die größte Stärke der Postman CLI ist, dass sie in der Welt bleibt, die Ihr Team bereits kennt. Wenn Ihre Sammlungen, Umgebungen und freigegebenen Variablen bereits in einem Postman-Arbeitsbereich leben, führt die CLI sie mit nahezu keiner Übersetzung aus. Sie bauen nichts neu auf. Sie authentifizieren sich, benennen die Sammlung, und sie führt die Anfragen und Tests genau so aus, wie es die App tun würde.

Die Installation erfolgt mit einem einzigen Befehl. Unter macOS und Linux führen Sie das offizielle Installationsskript aus:

curl -o- "https://dl-cli.pstmn.io/install/unix.sh" | sh

Unter Windows verwenden Sie den signierten PowerShell-Installer, und es gibt auch ein npm-Paket, falls Sie es lieber als Entwicklungsabhängigkeit festlegen möchten:

npm install -g postman-cli

Die ausführbare Datei ist `postman`. In CI authentifizieren Sie sich mit einem Postman API-Schlüssel, was die von Postman für Pipelines empfohlene Methode ist:

postman login --with-api-key $POSTMAN_API_KEY

Dann führen Sie eine Sammlung anhand ihrer ID oder eines lokalen Dateipfads aus, wenn Sie sie exportiert haben:

postman collection run $POSTMAN_COLLECTION_ID -e $POSTMAN_ENV_ID

Was der Postman CLI viel Loyalität einbringt, ist, was nach dem Lauf passiert. Wenn Sie angemeldet sind, sendet es die Laufergebnisse direkt an die Postman-Cloud, wo sie in Ihrem Arbeitsbereich neben der Sammlung angezeigt werden. Testhistorie, Laufvergleiche und das für das Team sichtbare Dashboard sind alle ohne zusätzliche Einrichtung vorhanden. Für ein Team, das bereits in Postman arbeitet, ist dieser Hin- und Rückweg wirklich nützlich, und es ist ein guter Grund zu bleiben.

Was die Apidog CLI gut kann

Apidog geht einen anderen Weg zur gleichen Pipeline. Sie erstellen Tests visuell in der Apidog-App: verketten Sie mehrere Anfragen zu einem einzigen Testszenario, fügen Sie Behauptungen zu jeder Antwort hinzu, ziehen Sie einen Wert aus einer Antwort und speisen Sie ihn in die nächste Anfrage ein, und wiederholen Sie das gesamte Szenario über eine Datendatei. Die CLI ist der kopflose Executor für diese Szenarien. Sie hat kein eigenes Testformat. Sie greift in Ihr Apidog-Projekt, findet das Szenario, das Sie anhand der ID benennen, und führt es genau so aus, wie es die App tun würde, und meldet dann das Ergebnis zurück.

Der Vorteil ist, dass niemand zwei Kopien desselben Tests pflegt. Das Szenario, das Sie im visuellen Editor erstellt haben, ist der Test, der in CI ausgeführt wird. Es gibt keinen Schritt, in dem Sie einen funktionierenden Test als Skript neu ausdrücken und dann das Skript debuggen. Die schnelle Erstellungsschleife und die Automatisierungsschleife teilen sich eine einzige Quelle der Wahrheit. Für mehrstufige Abläufe, wie Anmelden, dann Erstellen, dann Lesen, dann Löschen, spart diese visuelle Verkettung viel von dem Klebstoffcode, den Sie sonst manuell schreiben müssten. Die Mechanik zum Aufbau dieser Abläufe wird im Leitfaden zu Testszenarien für die API-Testautomatisierung behandelt.

Die Installation erfolgt mit einem npm-Befehl:

npm install -g apidog-cli

Die ausführbare Datei ist `apidog`. Eine typische Ausführung benennt ein Szenario anhand einer ID, wählt eine Umgebung aus, legt eine Iterationsanzahl fest und authentifiziert sich mit einem Zugriffstoken:

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

Sie geben diese IDs nicht manuell ein. Öffnen Sie das Testszenario in Apidog, wechseln Sie zum CI/CD-Tab, klicken Sie, um ein Zugriffstoken zu generieren, und Apidog erstellt den vollständigen Befehl für Sie mit bereits ausgefüllter Szenario-ID und Umgebungs-ID. Sie kopieren ihn einmal, verschieben das Token in ein CI-Geheimnis und referenzieren es als `$APIDOG_ACCESS_TOKEN` in Ihrem Workflow.

Das Token- und ID-Modell ist die klarste Abgrenzung von der Postman CLI. Apidog führt Tests aus, die in einem Projekt gespeichert sind, das die CLI über das Netzwerk abruft und durch das Token authentifiziert. Es gibt auch keine separate Cloud-Opt-in-Option für die Berichterstattung: Sie wählen `--out-dir` für lokale Artefakte und fügen `--upload-report` nur hinzu, wenn Sie eine Übersicht in die Apidog-Cloud übertragen möchten. Die Berichte bleiben dort, wo Sie sie ablegen.

Im Vergleich

Zwei Dinge fallen an dieser Tabelle auf. Erstens decken beide Runner die CI-Grundlagen in nahezu gleicher Form ab: Umgebungsselektion, datengesteuerte Iteration, die vier wichtigen Berichtsformate und ein Nicht-Null-Exit bei Fehlschlag. Wenn Sie lediglich einen Runner benötigen, der bei einem schlechten Merge rot wird, erledigt jeder von ihnen die Aufgabe. Zweitens geht es bei der eigentlichen Trennlinie darum, wo der Test lebt und wie Sie ihn geschrieben haben. Die Postman CLI führt eine Sammlung aus, die in Ihrem Postman-Arbeitsbereich lebt. Die Apidog CLI führt ein visuelles Szenario aus, das in Ihrem Apidog-Projekt lebt.

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

Ein Runner beweist seinen Wert in einer Pipeline durch zwei Verhaltensweisen: den Bericht, den er schreibt, und den Exit-Code, den er zurückgibt. Wenn diese beiden stimmen, ist alles andere nur noch Verdrahtung.

Die Postman CLI akzeptiert eine kommagetrennte Reporterliste, und wenn Sie angemeldet sind, werden die Ergebnisse auch an die Postman-Cloud gesendet:

postman collection run $POSTMAN_COLLECTION_ID \
  -e $POSTMAN_ENV_ID \
  --reporters cli,junit \
  --bail

Der `junit`-Reporter ist derjenige, den Ihr CI-Dashboard in einen Bestanden- oder Fehlgeschlagen-Baum parst. Das `--bail`-Flag stoppt die Ausführung bei der ersten fehlgeschlagenen Anfrage, dem ersten Test oder der ersten Behauptung, was das Feedback bei einem Smoke-Test schnell hält. Lassen Sie `--bail` weg, und es wird alles ausgeführt, und dann werden alle Fehler zusammen gemeldet. Die CLI beendet sich bei jedem Fehler mit einem Nicht-Null-Wert, sodass der Build von selbst rot wird.

Die Apidog CLI verwendet die gleiche `-r`-Reporter-Idee 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 beeinflusst das Verhalten während des Szenarios: `end` stoppt beim ersten Fehler und ist die Standardeinstellung, `continue` führt jeden Schritt aus, sodass Sie alle Fehler in einem Bericht sammeln, und `ignore` überspringt einen bekanntermaßen instabilen Schritt, ohne den Lauf zu unterbrechen. So oder so endet der Prozess mit einem Nicht-Null-Wert, wenn etwas fehlgeschlagen ist, und das JUnit XML landet in `./apidog-reports`, bereit für Ihr Dashboard.

Das praktische Ergebnis: Beide schreiben JUnit XML, beide lassen den Build korrekt fehlschlagen und beide archivieren einen HTML-Bericht, den Sie später öffnen können. Der Unterschied in der Berichterstattung liegt im Cloud-Roundtrip. Postman sendet Ergebnisse standardmäßig an seine Cloud, wenn Sie authentifiziert sind. Apidog behält Berichte lokal, es sei denn, Sie fordern den Upload an. Keines ist im abstrakten Sinne besser; das eine passt zu Teams, die eine gehostete Historie wünschen, ohne darüber nachzudenken, das andere zu Teams, die genau entscheiden möchten, was den Runner verlässt.

Jeden in GitHub Actions integrieren

Die Struktur eines GitHub Actions Jobs ist für beide gleich: Repo auschecken, Node einrichten, die CLI installieren, die Tests ausführen, und der fehlerhafte Exit-Code blockiert den Merge. Speichern Sie das Geheimnis in Ihren Repository-Einstellungen, niemals in der Workflow-Datei.

- name: API-Tests ausführen (Postman CLI)
  run: |
    curl -o- "https://dl-cli.pstmn.io/install/unix.sh" | sh
    postman login --with-api-key ${{ secrets.POSTMAN_API_KEY }}
    postman collection run $POSTMAN_COLLECTION_ID -e $POSTMAN_ENV_ID --reporters cli,junit --bail

Und die Apidog CLI-Version:

- name: API-Tests ausführen (Apidog CLI)
  run: |
    npm install -g apidog-cli
    apidog run --access-token ${{ secrets.APIDOG_ACCESS_TOKEN }} -t 605067 -e 1629989 -r cli,junit

Beide sind kurz, beide sind lesbar und beide verhalten sich auf der Ebene, die Ihre Pipeline interessiert, gleich: ein erfolgreicher Lauf beendet sich mit Null und der Merge wird fortgesetzt, ein fehlerhafter Lauf beendet sich mit einem Nicht-Null-Wert und der Merge wird blockiert. Wenn Sie eine tiefere Betrachtung der Ausführung von API-Tests in einem GitHub-Workflow wünschen, beschreibt API-Testautomatisierung mit GitHub Actions die Schritte. Für Jenkins-Benutzer ist die gleiche Idee in der Integration von automatisierten Apidog-Tests mit Jenkins dargelegt.

Welcher gewinnt also in CI?

Es gibt keinen einzigen Gewinner, denn die richtige Antwort hängt davon ab, wo Ihre Tests bereits leben und wie Ihr Team sie erstellen und speichern möchte.

Die Apidog CLI gewinnt, wenn Sie visuelle Erstellung und eine einzige Quelle der Wahrheit mehr schätzen als eine gehostete Cloud-Historie. Sie erstellen ein Szenario einmal im visuellen Editor, wobei Anforderungsketten und Assertions für Sie erledigt werden, und dasselbe Szenario läuft in CI als Referenz. Sie entscheiden, ob Berichte lokal bleiben oder hochgeladen werden. Und da Apidog Design, Mocking und Dokumentation im selben Arbeitsbereich abdeckt, liegt das Testszenario neben dem API-Vertrag, den es überprüft, was verhindert, dass Tests und Spezifikationen auseinanderdriften. Teams, die die Plattformen umfassender bewerten, können den vollständigen Vergleich Apidog vs Postman lesen.

Die Postman CLI gewinnt, wenn Ihr Team bereits in Postman arbeitet. Ihre Sammlungen sind dort, Ihre Umgebungen sind dort, und Sie möchten die Laufaustorien in der Postman-Cloud haben, ohne etwas einrichten zu müssen. Der Cloud-Roundtrip bei jedem Lauf ist eine echte Bequemlichkeit für dieses Setup, und das Tool ist offiziell signiert und unterstützt. Wenn das Ihr Team beschreibt, bringt Ihnen der Wechsel des Runners wenig.

Wenn Sie sich bereits vom Postman-Cloud-Modell eingeschränkt fühlen oder einfach Tests einmal erstellen und überall ausführen möchten, ist der Schritt klar. Laden Sie Apidog herunter, erstellen Sie ein Szenario, öffnen Sie den CI/CD-Tab und kopieren Sie den generierten `apidog run`-Befehl in Ihre Pipeline. Das ist die gesamte Einrichtung.

FAQ

Ist die Postman CLI dasselbe wie Newman? Nein. Newman ist der ältere Open-Source-npm-Runner. Die Postman CLI ist ein neueres Tool, das auf Newmans Grundlage aufbaut, von Postman signiert und unterstützt wird und eine integrierte Berichterstattung an die Postman-Cloud bietet. Wenn Sie sich zwischen den beiden Postman-seitigen Optionen entscheiden, beschreibt Postman CLI vs Newman die Unterschiede.

Benötige ich für eine der CLIs in CI ein Konto oder Token? Ja, für beide, aber die Form unterscheidet sich. Die Postman CLI authentifiziert sich mit einem Postman API-Schlüssel über `postman login --with-api-key`. Die Apidog CLI authentifiziert sich mit einem Zugriffstoken, das als `--access-token` übergeben wird. Speichern Sie beides als CI-Geheimnis, niemals in der Workflow-Datei.

Lassen beide Runner den Build fehlschlagen, wenn ein Test fehlschlägt? Ja. Beide beenden sich mit einem Nicht-Null-Statuscode bei jedem fehlgeschlagenen Test oder jeder fehlgeschlagenen Behauptung, was Ihrem CI-System mitteilt, den Build als rot zu markieren und den Merge zu blockieren. Die Postman CLI verwendet `--bail`, um beim ersten Fehler zu stoppen; die Apidog CLI verwendet `--on-error end`, was ihre Standardeinstellung ist.

Kann ich meine Berichte lokal behalten, anstatt sie in eine Cloud zu senden? Die Apidog CLI behält Berichte standardmäßig lokal und schreibt sie nach `--out-dir`; Sie laden nur mit `--upload-report` hoch. Die Postman CLI schreibt ebenfalls lokale Reporter, aber wenn Sie angemeldet sind, sendet sie die Laufergebnisse auch automatisch an die Postman-Cloud.

Wie erhalte ich den genauen Apidog-Ausführungsbefehl für mein Szenario? Öffnen Sie das Testszenario in Apidog, wechseln Sie zum CI/CD-Tab, generieren Sie ein Zugriffstoken, und Apidog erstellt den vollständigen `apidog run`-Befehl mit bereits ausgefüllter Szenario-ID und Umgebungs-ID. Kopieren Sie ihn, verschieben Sie das Token in ein CI-Geheimnis, und Sie sind fertig. Für jedes verfügbare Flag führen Sie `apidog run --help` aus.

Welchen sollte ein Team wählen, das von der Postman-Cloud migriert? Wenn der Grund für Ihren Weggang das Cloud-zentrierte Modell oder die Preisgestaltung ist, passt die Apidog CLI, da sie ein einziges visuelles Szenario aus Ihrem Projekt ausführt und Ihnen die Entscheidung überlässt, was den Runner verlässt. Beginnen Sie mit dem Vergleich Apidog vs Postman, um zu sehen, wie die Plattformen über den Runner hinaus ausgerichtet sind.