Apidog CLI vs Newman: API-Tests in CI ausführen (2026)

Ihre API-Tests bestehen auf Ihrem Laptop. Die schwierigere Frage ist, ob sie bei jedem Pull Request, jedem Merge und 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 geschriebenen Tests, führt sie kopflos in Ihrer Pipeline aus, beendet sich mit einem Statuscode, den Ihr CI lesen kann, und schreibt einen Bericht, den Ihr Dashboard parsen kann. Keine GUI, kein manueller Schritt, keine Ausrede, den Lauf zu überspringen.

Jahrelang war die Standardantwort auf diesen Bedarf Newman, der Open-Source-Kommandozeilen-Collection-Runner von Postman. Es ist ein solides, gut verstandenes Werkzeug, und viele Teams greifen immer noch zuerst danach. Wenn Sie Ihre Tests jedoch in Apidog anstelle von Postman erstellen, haben Sie eine zweite Option: die Apidog CLI, die dieselben Testszenarien ausführt, die Sie visuell in der App erstellen, und zwar kopflos in CI. Dieser Artikel ist ein ehrlicher Vergleich der beiden auf Kommandoebene. Er behandelt, was Newman gut macht, wo die Apidog CLI passt und wie sich jedes anfühlt, wenn es einmal in eine echte Pipeline integriert ist.

TL;DR

• Newman (newman, installiert über npm install -g newman) führt eine exportierte Postman Collection JSON-Datei aus. Es ist Open Source, kostenlos und liest eine Collection plus eine Umgebungsdatei von der Festplatte oder einer URL. Es unterstützt Umgebungen, Datendateien, Iterationszählungen und JUnit/JSON/HTML-Reporter und beendet sich mit einem Status ungleich Null, wenn ein Test fehlschlägt.
• Apidog CLI (apidog-cli, Binärdatei apidog) führt die Testszenarien aus, die Sie in der Apidog-App entwerfen und die über eine ID mittels eines Access Tokens abgerufen werden. Sie exportieren nichts und pflegen keine JSON-Datei manuell; das visuelle Szenario ist der Test, und die CLI führt es genau so aus, wie es die App tun würde.
• Beide lassen sich in GitHub Actions, GitLab CI, Jenkins und alles, was mit Node.js läuft, integrieren. Beide lassen den Build bei einem fehlgeschlagenen Test fehlschlagen. JUnit XML ist das, was in CI-Dashboards auf beiden Seiten integriert wird.
• Wählen Sie **Newman**, wenn Ihre Tests bereits als Postman Collections existieren und Sie einen kostenlosen, repo-freundlichen Runner ohne neues Konto wünschen.
• Wählen Sie **Apidog CLI**, wenn Sie visuelles Authoring, Anforderungsketten, Umgebungsverwaltung und datengesteuerte Ausführungen wünschen, die mit demselben Szenario synchron bleiben, das Ihr Team täglich debuggt.

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. Mehr Tests beheben das nicht. Tests, die bei jeder Änderung automatisch ausgeführt werden, tun dies, weil sie ein Bestanden- oder Fehlschlag-Signal erzeugen, auf das Ihre Pipeline reagieren kann.

Ein CLI-Runner schließt diese Lücke. Um in CI nützlich zu sein, muss er drei Dinge tun: ohne GUI ausgeführt werden, bei einem Fehler mit einem Status ungleich Null beendet werden, damit der Build rot wird, und einen maschinenlesbaren Bericht schreiben, damit Prüfer sehen können, was kaputt ist. Newman und die Apidog CLI erfüllen beide diese Anforderungen sauber. Wo sie sich unterscheiden, liegt vor dem Run-Befehl, nämlich darin, wie der Test geschrieben wurde und wo er lebt. Wenn Sie CI von Grund auf einrichten, passen die breiteren Muster in wie man API-Tests in CI/CD automatisiert gut zu diesem Vergleich. Hier konzentrieren wir uns auf die beiden Runner.

Was Newman gut macht

Newman hat sich seinen Platz verdient. Es ist der offizielle Open-Source-Begleiter zu Postman, und für Teams, deren Tests bereits als Postman Collections existieren, ist es der direkteste Weg von „Tests auf meinem Rechner“ zu „Tests in CI“. Es lohnt sich, seine Stärken vor jedem Vergleich klar darzulegen.

Es ist kostenlos und Open Source. Sie installieren es von npm und führen es überall aus, wo Node.js läuft, ohne eine separate Lizenz für den Runner selbst. Ihre Collection ist eine portable JSON-Datei, die Sie in ein Repository committen, als Build-Artefakt speichern oder von einer URL abrufen können. Diese Portabilität ist real und bedeutet, dass Newman reibungslos in fast jede Pipeline integriert werden kann.

Es verwendet wieder, was Sie bereits erstellt haben. Wenn Ihr Team Anfragen, Pre-Request-Skripte und Test-Assertions in Postman schreibt, führt Newman dieselben Collections unverändert aus. Es gibt keine Neuentwicklung. Die Skripte, die Sie im Postman-Editor geschrieben haben, werden im Headless-Run auf die gleiche Weise ausgeführt, was die Lernkurve für Postman-Anwender flach hält.

Die Installation erfolgt mit einem Befehl:

npm install -g newman

Die Binärdatei ist newman. Sie führen eine exportierte Collection aus, indem Sie sie auf die JSON-Datei verweisen, normalerweise zusammen mit einer Umgebungsdatei:

newman run api-tests.postman_collection.json -e staging.postman_environment.json

Das ist der Kernzyklus. Exportieren Sie die Collection aus Postman, committen Sie die JSON-Datei und führen Sie sie aus. Newman liest die Anfragen und Assertions aus der Datei und führt sie der Reihe nach aus. Für den vollständigen Einrichtungspfad behandelt Apidogs eigene Anleitung zu wie man Newman installiert und Postman Collections ausführt den Export- und Ausführungsablauf Schritt für Schritt.

Newman unterstützt auch die CI-Grundlagen, die Sie erwarten würden. Datengesteuerte Ausführungen stammen aus einer CSV- oder JSON-Datei:

newman run api-tests.postman_collection.json \
  -e staging.postman_environment.json \
  -d users.csv \
  -n 5

Hier liefert -d die Datendatei und -n setzt die Iterationsanzahl, sodass die Collection einmal pro Zeile oder eine feste Anzahl von Malen ausgeführt wird. Dies sind dieselben Grundfunktionen, die jeder ernsthafte Runner benötigt, und Newman verfügt seit Jahren über sie.

Wo Newman anfängt, Nachteile mit sich zu bringen

Die oben genannten Stärken sind ehrlich, aber das gilt auch für die Kompromisse, und diese zeigen sich eher im täglichen Wartungsaufwand als in einem einzelnen Befehl.

Der größte Punkt ist der Exportschritt. Eine Postman Collection in CI ist ein Schnappschuss. Sie erstellen und debuggen in der Postman-App, exportieren dann eine JSON-Datei, um sie kopflos auszuführen. In dem Moment, in dem jemand eine Anfrage in der App bearbeitet und vergisst, neu zu exportieren, weicht Ihre committete Collection von der Quelle der Wahrheit ab. Der CI-Lauf wird weiterhin gegen eine alte Definition ausgeführt, während die reale API sich weiterentwickelt hat. Nichts in den Tools zwingt die beiden wieder zur Synchronisation; es liegt an demjenigen, der sich an den Export erinnert.

Scripting ist der andere Punkt. Die Postman-Testlogik befindet sich in JavaScript-Snippets, die an jede Anfrage angehängt sind, und diese Skripte sind der Ort, an dem Verkettungen, Variablenauszüge und Assertions stattfinden. Das ist flexibel, bedeutet aber, dass Ihre Testsuite ein Haufen kleiner Skripte ist, die manuell geschrieben, debuggt und gewartet werden müssen. Mit zunehmender Größe der Szenarien wächst auch die Skriptoberfläche, die Sie besitzen. Dies ist Teil eines breiteren Musters, auf das Teams stoßen, wenn Collections skaliert werden, was wir in Postman Collection Runner Einschränkungen und wie man sie umgeht behandeln.

Nichts davon macht Newman zu einem schlechten Werkzeug. Es macht es zu einem Runner, dessen Ergonomie an das Authoring-Modell von Postman gebunden ist: Skripte plus ein Exportschritt. Wenn dieses Modell zu Ihrem Team passt, ist Newman in Ordnung. Wenn der Export- und Synchronisations-Tanz der Teil ist, der immer wieder Probleme verursacht, dann ist das genau der Punkt, an dem ein anderer Runner hilft.

Was die Apidog CLI anders macht

Apidog beschreitet einen anderen Weg zur gleichen Pipeline. Sie erstellen Tests visuell in der Apidog-App. Sie verketten Anfragen zu einem Testszenario, fügen Assertions in einem No-Code-Editor hinzu, ziehen einen Wert aus einer Antwort in die nächste Anfrage und durchlaufen das Ganze über eine Datendatei. Die CLI ist der kopflose Executor für diese Szenarien. Sie hat kein separates Dateiformat und nichts zu exportieren. Sie ruft das von Ihnen benannte Szenario anhand der ID aus Ihrem Apidog-Projekt ab und führt es genau so aus, wie es die App tun würde.

Das beseitigt das Drift-Problem. Das Szenario im Projekt ist der Test. Es gibt keinen exportierten Schnappschuss, der aus dem Takt geraten könnte, da die CLI das Live-Szenario ausführt, nicht eine Kopie davon. Sie erstellen es einmal in einem visuellen Builder, der das Verketten von Anfragen und Assertions für Sie übernimmt, und dann läuft dasselbe Szenario in CI. Der schnelle Authoring-Zyklus und der Automatisierungszyklus teilen sich eine einzige Quelle der Wahrheit.

Die Installation erfolgt mit einem npm-Befehl:

npm install -g apidog-cli

Die Binärdatei ist apidog. Ein typischer Lauf benennt ein Szenario über eine ID, wählt eine Umgebung aus und authentifiziert sich mit einem Access Token:

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, generieren Sie ein Access Token, und Apidog erstellt den vollständigen Befehl für Sie mit bereits ausgefüllter Szenario-ID und Umgebungs-ID. Sie kopieren es einmal, verschieben das Token dann in ein CI-Geheimnis und referenzieren es als $APIDOG_ACCESS_TOKEN. Wenn Sie nicht sicher sind, welche Flags Ihre installierte Version unterstützt, führen Sie apidog run --help aus, und es werden die genau verfügbaren Optionen angezeigt.

Das Token-basierte, ID-abrufende Modell ist der deutlichste Unterschied zu Newman. Newman liest eine Collection-Datei von der Festplatte; die Apidog CLI greift authentifiziert über das Netzwerk in ein Projekt und führt das dort gespeicherte Szenario aus. Keines ist falsch. Sie passen zu unterschiedlichen Team-Setups, und die Wahl hängt hauptsächlich davon ab, ob Sie möchten, dass der Test als exportierte Datei oder als Live-Szenario in einem gemeinsamen Arbeitsbereich existiert.

Gegenüberstellung

Zwei Dinge fallen auf. Erstens decken beide Runner dieselben CI-Grundlagen ab: Umgebungsselektion, datengesteuerte Iteration, die wichtigen Berichtsformate und einen Exit-Code ungleich Null bei Fehlschlag. Die Flag-Namen sind sogar ähnlich genug, dass sich das Muskelgedächtnis überträgt (-e, -d, -n, -r). Zweitens ist die eigentliche Trennung nicht die reine Funktionalität. Es ist vielmehr, wo der Test lebt und wie Sie ihn geschrieben haben. Newman führt eine exportierte Collection aus, die mit Skripten erstellt wurde. Apidog führt ein visuelles Live-Szenario per Referenz aus. Die detailliertere Version dieses Vergleichs, die sich auf die beiden Postman-Welt-Runner konzentriert, finden Sie unter Postman CLI vs Newman, falls Sie diesen Blickwinkel wünschen.

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 Verkabelung.

Newman wählt Reporter mit dem Flag -r und einer kommagetrennten Liste aus. JUnit und JSON sind standardmäßig dabei; der HTML-Reporter ist das häufigste Add-on:

newman run api-tests.postman_collection.json \
  -e staging.postman_environment.json \
  -r cli,junit \
  --reporter-junit-export ./results/junit.xml

Das JUnit XML ist das, was Ihr CI-Dashboard in einen Bestehen- oder Fehlschlag-Baum parst. Newmans --bail-Flag stoppt den Lauf nach dem ersten Fehlschlag, was ein schnelles Feedback bei einem Smoke Test gewährleistet. Ohne es wird der Lauf abgeschlossen und jeder Fehler sofort gemeldet.

Die Apidog CLI verwendet dasselbe kommagetrennte -r-Flag 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 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. In jedem Fall beendet sich der Lauf mit einem Status ungleich Null, wenn etwas fehlgeschlagen ist.

Der Exit-Code-Vertrag ist auf beiden Seiten derselbe, und er ist der tragende Teil. Wenn eine Assertion fehlschlägt, beendet sich der Runner mit einem Status ungleich Null. CI liest diesen Code, markiert den Schritt als fehlgeschlagen, lässt den Job fehlschlagen und blockiert den Merge oder Deploy. Sie konfigurieren nichts Zusätzliches. Die eine Falle, die für beide identisch ist, ist das Verschlucken des Exit-Codes: Umwickeln Sie den Lauf in einer Shell-Pipeline oder hängen Sie || true an, und der Exit ungleich Null wird geschluckt, sodass das Gate stillschweigend aufhört zu funktionieren. Tun Sie das nicht. Für den breiteren Kontext zu Berichtsformaten zeigt datengesteuertes API-Testen mit CSV oder JSON, wie der Bericht mit den Iterationsdaten verknüpft ist.

Newman in GitHub Actions

Da die Collection eine exportierte Datei im Repository ist, ist der Workflow kurz. Code auschecken, Newman installieren, Collection ausführen, Bericht auch bei Fehlschlag 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 Newman
        run: npm install -g newman

      - name: Run API tests
        run: |
          newman run ./tests/api-tests.postman_collection.json \
            -e ./tests/staging.postman_environment.json \
            -r cli,junit \
            --reporter-junit-export ./results/junit.xml

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

Kein Geheimnis ist erforderlich, wenn die Collection- und Umgebungsdateien im Repository committet sind. Die Zeile if: always() sorgt dafür, dass der Bericht auch bei fehlgeschlagenen Tests hochgeladen wird, was genau dann der Fall ist, wenn Sie ihn lesen möchten. Der Preis, den Sie dafür zahlen, ist der Exportschritt, der diese JSON-Dateien überhaupt erst erstellt hat, und das Erinnern daran, sie zu aktualisieren, wenn sich die API ändert.

Apidog CLI in GitHub Actions

Der Apidog-Workflow hat dieselbe Form, mit einer Änderung: Das Access Token stammt aus Repository-Geheimnissen, und Sie wählen das Szenario über die ID aus, anstatt auf eine Datei zu verweisen.

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, gleiches Node-Setup, gleiche Install-dann-Run-Form, gleicher Always-Upload. Die einzigen wirklichen Unterschiede sind das als Geheimnis verdrahtete Token und das über die ID ausgewählte Szenario anstatt über den Dateipfad. Da das Szenario live abgerufen wird, gibt es keine JSON-Datei, die aktuell gehalten werden muss. Für dasselbe Muster in anderen Systemen überträgt wie man API-Tests in GitHub Actions automatisiert die Struktur auf GitLab CI und Jenkins.

Entscheidungshilfe

Die Entscheidung hängt selten davon ab, welcher Runner objektiv besser ist. Sie hängt davon ab, wo Ihre Tests bereits existieren und wie Ihr Team sie pflegen möchte.

• Wählen Sie Newman, wenn Ihre Tests bereits Postman Collections sind. Wenn Ihre Suite in Postman lebt, Ihr Team Testskripte im Editor schreibt und Sie einen kostenlosen, quelloffenen Runner wünschen, der ohne neues Konto in jede Pipeline integriert werden kann, ist Newman die direkte Wahl. Es ist die natürliche Wahl für Postman-Anwender, die sich mit dem Exportieren einer Collection und dem Committen der JSON-Datei wohlfühlen und nichts dagegen haben, die Testskripte manuell zu besitzen. Mehr über die Unterschiede innerhalb des Postman-Ökosystems können Sie unter was ist der Unterschied zwischen Newman und Postman lesen.
• Wählen Sie die Apidog CLI, wenn die Erstellungsgeschwindigkeit und eine einzige Quelle der Wahrheit wichtiger sind als der Verbleib in Postman. Wenn Sie lieber ein Testszenario visuell erstellen, Anfragen verketten, Variablen extrahieren und dasselbe Szenario über verschiedene Umgebungen hinweg ausführen möchten, ohne Testcode schreiben und neu exportieren zu müssen, beseitigt Apidog diese Reibung. Entwerfen, debuggen, mocken und testen Sie live in einem Arbeitsbereich, und die CLI führt genau das von Ihnen erstellte Szenario aus. Für Teams, die von Postman wechseln, ist die Migration etwas, das Apidog als Postman-Alternative für API-Tests abdeckt, und der Import ist ein einziger Klick.

Es gibt auch eine Antwort für beide Tools. Einige Teams lassen einen bestehenden Newman-Schritt ihre älteren Collections ausführen, während sie neue, komplexere verkettete Szenarien in Apidog verschieben. Die beiden CLIs koexistieren problemlos in einer Pipeline; es sind separate Schritte mit separaten Exit-Codes, und Sie können den Newman-Schritt nach Ihrem eigenen Zeitplan ausmustern.

Um Ihr erstes automatisiertes Szenario einzurichten und es noch am selben Nachmittag vom Terminal auszuführen, laden Sie Apidog herunter, erstellen Sie ein Testszenario und kopieren Sie den generierten Befehl aus dem CI/CD-Tab.