Datengetriebenes API-Testing mit der Apidog CLI: CSV- und JSON-Iterationen

Sie haben ein solides Testszenario für Ihren Checkout-Endpunkt erstellt. Es verknüpft drei Anfragen, überprüft jede Antwort und besteht jedes Mal, wenn Sie auf Ausführen klicken. Dann benötigt Ihre Pipeline, dass es vierzig Eingabekombinationen abdeckt, die Daten aus einer Datei abruft, die Ihr QA-Leiter pflegt, und dasselbe Szenario mit unterschiedlichen Anmeldeinformationen gegen Staging und Produktion ausführt. Die Point-and-Click-Ausführung, die auf Ihrem Laptop funktionierte, lässt sich nicht darauf übertragen, und Sie möchten das Szenario nicht vierzig Mal klonen.

Diese letzte Meile wird von der Befehlszeile erledigt. Mit Apidog erstellen Sie ein Testszenario einmal im visuellen Builder und steuern es dann über ein Terminal mit dem apidog-cli Paket. Das Flag, das ein Szenario in einen datengesteuerten Lauf verwandelt, ist -d, kurz für --iteration-data. Es nimmt eine CSV-Datei, eine JSON-Datei oder einen Datensatz, den Sie in Ihrem Apidog-Projekt gespeichert haben, und führt das Szenario einmal pro Zeile aus, wobei die Werte jeder Zeile an die Variablen gebunden werden, auf die Ihre Anfragen verweisen.

Wie das -d Flag eine Datei liest

Die gesamte Funktion steckt in einer Option. Hier ist die Lang- und Kurzform, direkt aus apidog run --help:

-d, --iteration-data <path|testDataId>   Define the data which use for iterations (either JSON or CSV)

Dieses <path|testDataId> ist das Detail, das die meisten Leute übersehen. Das Argument ist überladen. Übergeben Sie einen Pfad und die CLI liest eine lokale Datei von der Festplatte. Übergeben Sie eine Testdaten-ID und die CLI ruft einen Datensatz ab, den Sie in Ihrem Apidog-Projekt gespeichert haben. Dasselbe Flag, zwei Quellen, und der Runner findet heraus, welche Sie übergeben haben.

Die lokale Datei ist der übliche Ausgangspunkt. Zeigen Sie auf eine Datei relativ zu dem Ort, an dem Sie den Befehl ausführen:

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d ./test-data/checkout-cases.csv -r cli

Die CLI öffnet checkout-cases.csv, zählt die Zeilen unter dem Header und führt Szenario 605067 einmal pro Zeile aus. Bei jedem Durchlauf bindet es die Spalten an die passenden Variablen in Ihren Anfragen, feuert das Szenario ab und protokolliert das Ergebnis dieser Iteration. Vierzig Zeilen, vierzig Durchläufe, ein Szenario.

Das Format folgt der Datei. Dasselbe Flag akzeptiert JSON ohne zusätzliche Option:

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d ./test-data/checkout-cases.json -r cli

Sie müssen der CLI nicht mitteilen, welches Format Sie verwenden. Sie liest die Erweiterung und die Dateistruktur. Das bedeutet, dass Sie mitten im Projekt eine CSV-Datei gegen ein JSON-Array austauschen können, ohne den Befehl zu ändern, solange die Spaltennamen und die JSON-Schlüssel mit den Variablen übereinstimmen, die Ihr Szenario erwartet.

Was die CLI in jeder Datei erwartet

CSV ist das Format für flache, tabellarische Fälle. Die Kopfzeile benennt Ihre Variablen. Jede darunterliegende Zeile ist eine Iteration. Hier ist eine echte checkout-cases.csv für einen Rabatt-Endpunkt:

sku,quantity,coupon,expected_status,expected_total
DESK-01,1,SAVE10,200,89.10
DESK-01,0,SAVE10,422,0
CHAIR-09,3,,200,447.00
DESK-01,1,EXPIRED,410,0
GHOST-99,1,SAVE10,404,0

Fünf Spalten werden zu fünf Variablen. Im Anfragetext schreiben Sie {{sku}} und {{quantity}}; in den Zusicherungen vergleichen Sie die Antwort mit {{expected_status}} und {{expected_total}}. Der Runner bindet sie pro Zeile. Die leere coupon-Zelle in Zeile drei wird zu einem leeren String, was genau der Fall ohne Coupon ist, den Sie abdecken möchten.

JSON ist das Format, wenn Ihre Fälle eine verschachtelte Struktur aufweisen, die sich schlecht in Spalten aufteilen lässt. Die Datei ist ein Array von Objekten, ein Objekt pro Iteration:

[
  {
    "label": "valid order, two items",
    "order": {
      "items": [
        { "sku": "DESK-01", "qty": 1 },
        { "sku": "CHAIR-09", "qty": 2 }
      ],
      "shipping": { "country": "US", "method": "ground" }
    },
    "expected_status": 200
  },
  {
    "label": "unshippable country",
    "order": {
      "items": [{ "sku": "DESK-01", "qty": 1 }],
      "shipping": { "country": "ZZ", "method": "ground" }
    },
    "expected_status": 422
  }
]

Im Szenario verweisen Sie auf {{order}} und {{expected_status}} auf dieselbe Weise, und der Runner übergibt die Felder jedes Objekts an die Iteration. Das label-Feld ist für Sie. Es erscheint im Bericht, sodass ein fehlgeschlagener Durchlauf "unshippable country" statt "iteration 2" anzeigt, was den Unterschied zwischen einer Fünf-Sekunden-Diagnose und einer Fünf-Minuten-Diagnose ausmacht.

Ein paar Regeln verhindern, dass diese Dateien Ihnen in der CI Probleme bereiten:

• Halten Sie die Kopfzeilennamen identisch mit den Variablennamen in Ihrem Szenario. Eine Spalte namens qty wird nicht an eine Anfrage gebunden, die {{quantity}} liest. Diese Nichtübereinstimmung ist der häufigste Grund, warum ein datengesteuerter Lauf lokal erfolgreich ist und in der Pipeline leere Werte erzeugt.
• Setzen Sie ein CSV-Feld, das ein Komma enthält, in Anführungszeichen, oder verschieben Sie diese Datei in JSON. Ein Freitextfeld mit einem Komma darin wird in zwei Spalten aufgeteilt und verschiebt jeden Wert danach.
• Legen Sie das erwartete Ergebnis in den Daten ab, nicht im Szenario. Zeile eins erwartet 200, Zeile vier erwartet 410. Wenn Sie die Erwartung in der Zusicherung fest codieren, sind Sie wieder bei einem Szenario pro Fall.
• Checken Sie diese Dateien zusammen mit Ihrer Testkonfiguration ein, damit sie mit dem Code versioniert werden, den sie testen. Die Datendatei ist Teil des Tests, kein loses Artefakt.

Für die JSONPath-Seite beim Schreiben von Zusicherungen, die diese gebundenen Werte lesen, wird in Zusicherungen festlegen und Variablen aus einer JSON-Antwort extrahieren die Syntax detailliert erläutert.

Ausführen mit einem gespeicherten Datensatz anstelle einer Datei

Die zweite Form von -d ist die, die in den meisten Anleitungen nicht auftaucht. Anstelle eines Pfades übergeben Sie eine Testdaten-ID:

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d 38291 -r cli

Jetzt ruft die CLI den Datensatz mit dieser ID aus Ihrem Apidog-Projekt ab, anstatt eine Datei von der Festplatte des Runners zu lesen. Dies ist nützlich, wenn die Daten beim Team und nicht im Repository liegen. Ihr QA-Leiter pflegt die Falltabelle in Apidog, bearbeitet sie in der App, und jeder CI-Lauf übernimmt die aktuelle Version, ohne dass jemand eine CSV-Datei commiten muss. Das Szenario, die Umgebung und die Daten sind alle serverseitig; der Befehl benennt sie einfach über die ID.

Der Kompromiss liegt darin, wo sich Ihre Quelle der Wahrheit befindet. Eine committed CSV-Datei bietet Ihnen einen Datensatz, der in Pull-Requests vergleichbar ist und an den getesteten Commit gebunden ist. Eine gespeicherte Testdaten-ID bietet Ihnen eine einzige gemeinsame Tabelle, die jeder an einem Ort bearbeitet. Beides ist nicht falsch. Wählen Sie die committed Datei, wenn die Daten synchron mit dem Code bewegt werden sollen, und die gespeicherte ID, wenn die Daten von Personen gepflegt werden, die das Repository nicht berühren.

Offline-Ausführung aus einer exportierten Datei

Es gibt eine dritte Möglichkeit, die CLI zu speisen, und sie verändert die Form des gesamten Befehls. Sie können einen Testfall aus Apidog als eigenständige Datei exportieren und diese Datei direkt ausführen, ohne Szenario-ID und ohne Netzwerk-Roundtrip, um das Szenario abzurufen:

apidog run ./checkout.apidog-cli.json -r cli,html

Hier ist das erste Argument eine file-source, der exportierte Testfall selbst, kein Flag. Die CLI führt aus, was in der Datei steht. Sie legen immer noch Iterationsdaten mit -d darüber:

apidog run ./checkout.apidog-cli.json -d ./checkout-cases.csv -r cli,junit

Dies ist in zwei Situationen relevant. Die erste ist ein luftgesperrter oder abgeschotteter CI-Runner, der die Apidog-Cloud nicht erreichen kann, um eine Szenario-ID aufzulösen; die exportierte Datei enthält alles, was für den Lauf benötigt wird. Die zweite ist die Reproduzierbarkeit: Die exportierte Datei ist ein eingefrorener Schnappschuss des Szenarios zum Zeitpunkt des Exports, sodass ein Lauf davon nicht davon beeinflusst wird, wenn jemand das Szenario später in der App bearbeitet. Für die Installations- und Erstaustührungsmechanismen dahinter deckt der Apidog CLI Installationsleitfaden die Bereitstellung des Binärprogramms ab, und die vollständige Apidog CLI-Referenz dokumentiert jedes Flag in einer Tabelle.

Kombinieren von -d mit -n und Variablenüberschreibungen

Datengesteuerte Läufe sind selten allein unterwegs. Drei Flags werden ständig mit -d kombiniert.

-n, --iteration-count legt fest, wie oft das Szenario ausgeführt wird. Wenn Sie eine Datendatei bereitstellen, bestimmt die Zeilenanzahl bereits die Iterationen, daher lassen Sie -n normalerweise weg und überlassen die Entscheidung der Datei. Sie verwenden -n hauptsächlich, wenn Sie die Tabelle mehr als einmal ausführen möchten oder wenn Sie überhaupt keine Datendatei verwenden, wie bei einem Belastungstest, der ein festes Szenario wiederholt:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -n 50 -r cli

--env-var und --global-var injizieren key=value-Paare zur Laufzeit, ohne die Umgebung in Ihrem Projekt zu berühren. So halten Sie Geheimnisse und pipeline-spezifische Konfigurationen sowohl aus dem Szenario als auch aus der Datendatei fern. Die Datendatei enthält die Testfälle; die Überschreibungen enthalten die Dinge, die sich pro Lauf ändern:

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d ./test-data/checkout-cases.csv \
  --env-var "base_url=https://staging.internal" \
  --global-var "api_key=$RUNTIME_API_KEY" \
  -r cli,junit

Die Aufteilung ist bewusst. Iterationsdaten sind der Teil des Laufs, der überall gleich ist: die Fälle, die Ihr Endpunkt behandeln muss. Die Variablenüberschreibungen sind der Teil, der sich pro Umgebung ändert: der Host, der Schlüssel, der Mandant. Bewahren Sie Anmeldeinformationen in Ihrem CI-Geheimnisspeicher auf und übergeben Sie sie über --global-var aus einer Umgebungsvariablen, so wie $RUNTIME_API_KEY oben. Backen Sie sie niemals in die CSV-Datei ein, wo jeder mit Repo-Zugriff sie lesen kann.

Lesen der Ergebnisse pro Iteration

Ein datengesteuerter Lauf ist nur nützlich, wenn Sie erkennen können, welche Zeile fehlgeschlagen ist. Die Reporter-Flags bestimmen, was Sie zurückerhalten.

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d ./test-data/checkout-cases.csv \
  -r cli,junit --out-dir ./test-reports

-r cli druckt eine lesbare Aufschlüsselung pro Iteration ins Terminal, die Sie in einem Build-Protokoll durchsuchen können. -r junit schreibt JUnit XML, das Format, das nahezu jedes CI-Dashboard in einen Bestanden/Fehlgeschlagen-Baum parst, sodass eine fehlerhafte Zeile als benannter fehlerhafter Test anstatt als verborgener Protokolltext angezeigt wird. Sie können auch html und json übergeben; html liefert einen durchsuchbaren Bericht zum Archivieren als Build-Artefakt, und json liefert rohe strukturierte Ausgabe, wenn Sie die Ergebnisse nachbearbeiten. --out-dir steuert, wo die Dateien landen, damit Sie sie als Artefakte aufbewahren können.

Standardmäßig stoppt der Lauf bei der ersten fehlerhaften Zusicherung. Bei einer großen Datentabelle ist das normalerweise der falsche Ansatz, da Sie jede fehlerhafte Zeile in einem Durchlauf sehen möchten, anstatt eine zu korrigieren und erneut auszuführen, um die nächste zu finden. Ändern Sie das Verhalten mit --on-error:

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d ./test-data/checkout-cases.csv \
  --on-error continue \
  -r cli,junit --out-dir ./test-reports

--on-error continue führt jede Iteration aus, auch wenn frühere fehlschlagen, sodass ein einziger Bericht Ihnen auf einmal anzeigt, dass die Zeilen zwei, sieben und neunzehn fehlerhaft sind. Der Lauf endet trotzdem mit einem Exit-Code ungleich Null, wenn etwas fehlgeschlagen ist, sodass er ein echtes Gate bleibt. --on-error end ist die schnelle Fehlerbehandlung für einen kurzen Smoke-Check; ignore ist für den seltenen, bekanntermaßen instabilen Schritt, der den Lauf nicht zum Scheitern bringen soll.

Fehlersuche bei einer Bindung, die stillschweigend nichts tut

Der Fehlermodus, der bei datengesteuerten Läufen die meiste Zeit verschwendet, ist keine rote Zusicherung. Es ist ein grüner Lauf, der nichts getestet hat, weil die Daten nie an die Anfrage gebunden wurden. Die Anfrage wurde mit leeren Werten ausgelöst, der Endpunkt gab eine 200 für eine leere Payload zurück, und die Zusicherung war erfolgreich. Die Abdeckung sieht gut aus; ist sie aber nicht.

Wenn ein datengesteuerter Lauf sich seltsam verhält, fügen Sie --verbose hinzu:

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d ./test-data/checkout-cases.csv \
  --verbose -r cli

--verbose druckt die vollständige Anfrage und Antwort für jede Iteration. Sehen Sie sich den Anfragetext an, den der Runner tatsächlich gesendet hat. Wenn Sie {{sku}} unersetzt oder einen leeren Wert sehen, obwohl die CSV-Zelle nicht leer war, ist die Bindung fehlgeschlagen. Drei übliche Ursachen, in der Reihenfolge ihrer Häufigkeit:

• Spaltenname und Variablenname stimmen nicht überein. Der CSV-Header ist product_sku und die Anfrage liest {{sku}}. Benennen Sie einen so um, dass sie identisch sind.
• Ein verirrtes Komma hat eine CSV-Zeile geteilt. Ein unquotierte Freitextfeld hat jede Spalte danach verschoben, sodass expected_status nun das enthält, was in der nächsten Spalte stehen sollte. Setzen Sie das Feld in Anführungszeichen oder wechseln Sie die Datei zu JSON.
• Der Pfad zur Datendatei ist relativ zum Arbeitsverzeichnis in CI falsch. Er wird auf Ihrem Laptop korrekt aufgelöst und liest in der Pipeline stillschweigend nichts. Verwenden Sie einen Pfad relativ zum Repo-Stammverzeichnis, den der Checkout-Schritt erzeugt, und bestätigen Sie die Existenz der Datei in einem Schritt vor dem Lauf.

Die allgemeine Regel: Wenn Iterationen erfolgreich sind, Sie aber vermuten, dass sie es nicht sein sollten, lesen Sie eine ausführliche Anfrage, bevor Sie dem grünen Ergebnis vertrauen. Ein Test, der gegen leere Eingaben läuft, ist schlimmer als kein Test, weil er Ihnen sagt, dass alles in Ordnung ist, während der Endpunkt ungetestet bleibt.

Einbindung in CI

Der Vorteil ist, dass die gesamte Tabelle bei jeder Änderung ausgeführt wird, ohne dass jemand auf "Ausführen" klicken muss. Hier ist ein GitHub Actions-Job, der die CLI installiert und ein CSV-gesteuertes Szenario bei jedem Pull Request ausführt:

name: Data-driven API tests
on: [pull_request]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install Apidog CLI
        run: npm install -g apidog-cli
      - name: Run data-driven scenario
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
        run: |
          apidog run --access-token $APIDOG_ACCESS_TOKEN \
            -t 605067 -e 1629989 \
            -d ./test-data/checkout-cases.csv \
            --on-error continue \
            -r cli,junit --out-dir ./test-reports
      - name: Upload report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: api-test-report
          path: ./test-reports

Das Token stammt von secrets.APIDOG_ACCESS_TOKEN, das einmal in den Repo-Einstellungen festgelegt wird. --on-error continue sammelt jede fehlerhafte Zeile in einem Bericht, anstatt bei der ersten anzuhalten. Das if: always() beim Hochladen bewahrt den Bericht auch dann auf, wenn der Lauf fehlschlägt, was der Zeitpunkt ist, an dem Sie ihn am dringendsten lesen möchten. Tauschen Sie den CSV-Pfad gegen eine JSON-Datei oder eine gespeicherte Testdaten-ID aus, und nichts anderes ändert sich.

Dieselben drei Schritte lassen sich auf jedes CI-System übertragen: Node.js und die CLI installieren, das Token als Umgebungsvariable verfügbar machen, apidog run mit -d aufrufen. GitLab CI, Jenkins, CircleCI und die anderen benötigen keine plattformspezifische Neuschreibung Ihrer Tests. Eine detailliertere Anleitung zur Actions-Seite finden Sie unter API-Tests in GitHub Actions automatisieren, und die vollständige Apidog CLI-Anleitung legt jede Option für die gesamte Flag-Oberfläche der CLI über Reporter, Fehlerbehandlung und TLS dar.

Ein Workflow, der skaliert, ohne den Test zu erweitern

Beginnen Sie mit einem Szenario und drei Zeilen. Erstellen Sie das Szenario in der App mit Variablenreferenzen in den Anfragen und dem erwarteten Ergebnis in den Zusicherungen. Schreiben Sie eine CSV-Datei mit einem Happy Path, einem bekannten Fehler und einem Grenzfall. Führen Sie es lokal mit -d aus, bis alle drei Iterationen funktionieren.

Dann erweitern Sie die Daten, nicht das Szenario. Jeder Fehlerbericht wird zu einer neuen Zeile mit der korrekten erwarteten Ausgabe. Der Fehler wird zu einem dauerhaften Regressionsfall, und Sie haben nie einen neuen Test geschrieben; Sie haben eine Zeile zu einer Datei hinzugefügt. Innerhalb weniger Monate sammelt diese Datei die tatsächlichen Probleme, denen Ihr Endpunkt in der Produktion gegenübersteht.

Fügen Sie schließlich den Befehl apidog run -d mit --on-error continue und dem junit-Reporter in Ihre CI ein. Nun führt eine Änderung, die die Zeile des abgelaufenen Coupons bricht, sofort nach dem Push zum Fehlschlagen des Builds, mit einer benannten Iteration, die direkt auf den fehlerhaften Fall verweist. Das Szenario bleibt eine kleine, lesbare Sache, egal wie breit die Tabelle wird. Das ist der sich verstärkende Gewinn: Die Abdeckung wächst durch Dateneingabe, und der Wartungsaufwand bleibt gleich.

Wenn Sie noch unsicher sind, ob ein CLI-Runner wie dieser zu Ihrem Stack passt im Vergleich zu einem Code-First-Framework, vergleicht die Aufschlüsselung unter Welches Tool für datengesteuertes API-Testing mit CSV oder JSON wählen die Ansätze, und Apidog CLI vs. Newman behandelt das nächstgelegene Kommandozeilen-Analogon aus der Postman-Welt.

Häufig gestellte Fragen

Kann -d sowohl einen Dateipfad als auch einen gespeicherten Datensatz annehmen? Das -d Flag akzeptiert pro Lauf entweder das eine oder das andere: einen lokalen CSV- oder JSON-Pfad oder eine Testdaten-ID, die auf einen in Ihrem Apidog-Projekt gespeicherten Datensatz verweist. Sie übergeben einen Wert. Verwenden Sie den Dateipfad, wenn die Daten mit Ihrem Repo versioniert werden sollen, und die gespeicherte ID, wenn eine gemeinsame Tabelle in der App existiert und Sie keine Kopie commiten möchten.

Muss ich der CLI mitteilen, ob meine Datei CSV oder JSON ist? Nein. Der Runner liest das Format aus der Datei selbst, sodass dasselbe -d Flag beides verarbeitet. Halten Sie Ihre Spaltennamen (CSV) oder Objektschlüssel (JSON) mit den Variablennamen überein, auf die Ihr Szenario verweist, und Sie können die Formate wechseln, ohne den Befehl zu ändern.

Was passiert, wenn ich -d und -n zusammen verwende? Die Zeilenanzahl der Datendatei bestimmt die Anzahl der Iterationen, daher ist -n in der Regel unnötig mit -d. Verwenden Sie -n, wenn Sie einen Lauf ohne Datendatei wiederholen möchten, z. B. einen Belastungstest, oder wenn Sie die gesamte Tabelle gezielt mehr als einmal ausführen möchten.

Warum wurde mein datengesteuerter Lauf erfolgreich ausgeführt, ohne etwas zu testen? Die häufigste Ursache ist eine Bindung, die nie stattgefunden hat: ein Spaltenname, der nicht mit dem Variablennamen übereinstimmt, oder ein falscher Dateipfad in der CI, der nichts gelesen hat. Führen Sie einen Lauf einmal mit --verbose durch und überprüfen Sie den Anfragetext, den die CLI gesendet hat. Wenn Sie unersetzt {{variables}} oder leere Werte sehen, beheben Sie die Namensdiskrepanz oder den Pfad, bevor Sie dem grünen Ergebnis vertrauen.

Wie halte ich Anmeldeinformationen aus meiner Datendatei fern? Halten Sie Tokens und Schlüssel vollständig aus der CSV- oder JSON-Datei heraus. Übergeben Sie sie zur Laufzeit mit --global-var oder --env-var aus Ihrem CI-Geheimnisspeicher, so wie Sie --global-var "api_key=$RUNTIME_API_KEY" übergeben würden. Die Datendatei sollte Testeingaben und erwartete Ergebnisse enthalten, nichts, was den Lauf authentifiziert.

Kann ich dieselben Daten gegen Staging und Produktion ausführen? Ja. Behalten Sie das Szenario und die Datendatei bei und wechseln Sie das Ziel mit -e. Verweisen Sie einen Pull-Request-Check auf eine Staging-Umgebungs-ID und einen Smoke-Test nach dem Deployment auf die Produktion, indem Sie dasselbe Szenario und dieselben Daten verwenden, nur einen anderen -e-Wert. Die Trennung von Umgebung und Daten ist der Hauptgrund, warum dies funktioniert.

Zusammenfassung

Das -d Flag ist die gesamte datengesteuerte Geschichte für die Apidog CLI, und es ist flexibler, als es auf den ersten Blick scheint. Es liest eine lokale CSV- oder JSON-Datei oder einen Datensatz, der in Ihrem Projekt über die ID gespeichert ist. Es wird mit -n für Wiederholungen, mit --env-var und --global-var für die Konfiguration pro Lauf und mit --on-error continue gekoppelt, sodass ein Lauf jede fehlerhafte Zeile aufdeckt. Führen Sie es online über eine Szenario-ID oder offline aus einer exportierten Datei aus und lesen Sie die Ergebnisse pro Iteration über die junit- und cli-Reporter.

Erstellen Sie das Szenario einmal, beschreiben Sie jeden Fall als Zeile, und lassen Sie den Runner Ihre Abdeckung erweitern, jedes Mal, wenn jemand eine Zeile zur Datei hinzufügt. Laden Sie Apidog herunter, richten Sie apidog run auf Ihre erste Datendatei und verwandeln Sie ein einzelnes Szenario in eine Tabelle von Fällen, die bei jedem Push ausgeführt wird.