Die Hoppscotch CLI ist eine saubere, kostenlose Möglichkeit, API-Sammlungen in einem Terminal oder einer CI-Pipeline auszuführen. Der Befehl `hopp test` liest eine Sammlungsdatei, führt jede Anfrage aus, führt Ihre Pre-Request- und Testskripte aus und beendet den Vorgang mit einem von Null verschiedenen Code, wenn eine Assertion fehlschlägt. Für viele Teams ist das ausreichend.
Aber ein Runner ist nur ein kleiner Teil der API-Arbeit. Irgendwann jonglieren Sie mit einem separaten Designtool, einem Mock-Server, einer Doku-Site und dem Runner, und keines davon teilt eine einzige Quelle der Wahrheit. Dann beginnen Teams normalerweise, sich mit der Migration von der Hoppscotch CLI zur Apidog CLI zu beschäftigen. Apidog integriert Design, Debugging, Mocking, Dokumentation und Tests in eine einzige Plattform, und seine CLI führt den Testteil in CI aus. Der Runner bleibt in der Form, die Sie bereits kennen. Was sich ändert, ist alles drumherum.
Wann Sie migrieren sollten (und wann nicht)
Seien Sie zuerst ehrlich zu sich selbst. Wenn Ihre einzige Anforderung lautet: „Eine Sammlung in CI kostenlos ausführen, bei Bedarf selbst hosten“, ist die Hoppscotch CLI ein wirklich gutes Tool. Sie ist Open Source, der Runner ist schnell und `@hoppscotch/cli` wird als normales npm-Paket ausgeliefert. Es gibt keinen Grund, nicht zu bleiben.
Migrieren Sie, wenn eines der folgenden Probleme auftritt:
- Sie entwerfen APIs in einem Tool, erstellen Mocks in einem anderen und schreiben Dokumentationen in einem dritten, und das Synchronisieren ist manuelle Arbeit.
- Sie möchten, dass Testläufe, Mock-Server und veröffentlichte Dokumentation eine einzige Projektdefinition teilen.
- Sie benötigen umfangreichere Berichte (HTML-Berichte für Stakeholder, JSON für Maschinen) sowie eine in der Cloud gehostete Laufhistorie.
- Sie möchten Endpunkte, Schemas, Umgebungen und Branches als Code behandeln, den die CLI verwalten und nicht nur ausführen kann.
Wenn diese Liste nach Ihrer Arbeitswoche klingt, ist die Plattform der Grund für den Wechsel, nicht der Runner. So geht es sauber:
Schritt 1: Exportieren Sie Ihre Hoppscotch-Sammlung und -Umgebung
Alles in Hoppscotch ist JSON, was den Export schmerzfrei macht.
Öffnen Sie in der Hoppscotch-App (Web oder Desktop) die Sammlung, die Sie in CI ausführen. Verwenden Sie das Menü der Sammlung und wählen Sie Exportieren, wodurch Sie eine `.json`-Datei erhalten. Machen Sie dasselbe für die Umgebung, die Sie mit `-e` übergeben: Öffnen Sie das Umgebungsfenel und exportieren Sie diese in eine eigene JSON-Datei.
Wenn Sie die CLI bereits mit lokalen Dateien ausführen, haben Sie diese bereits auf der Festplatte. Ein typischer Hoppscotch CI-Schritt sieht so aus:
npm i -g @hoppscotch/cli
hopp test ./collections/checkout-api.json -e ./environments/staging.json
Behalten Sie beide Dateien. `checkout-api.json` ist Ihre Sammlung, `staging.json` ist Ihre Umgebung. Diese beiden sind die gesamte Nutzlast, die Sie übernehmen.
Ein Hinweis zu Node-Versionen, solange wir dabei sind. Die aktuelle Hoppscotch CLI benötigt Node.js v22 oder neuer; Teams, die an Node 20 gebunden sind, bleiben bei CLI v0.26.0. Die Apidog CLI bindet Sie nicht daran, daher ist eine Migration auch eine Chance, eine Versionsbeschränkung aufzuheben.
Schritt 2: Importieren Sie die Sammlung in Apidog
Erstellen Sie ein Projekt in Apidog (oder öffnen Sie ein bestehendes) und importieren Sie dann Ihren Hoppscotch-Export. Apidog liest gängige Sammlungsformate und OpenAPI, sodass Sie die Sammlung direkt importieren können. Wenn Ihre API auch eine OpenAPI-Spezifikation hat, importieren Sie diese ebenfalls. Apidog validiert die Spezifikation beim Import, sodass strukturelle Probleme sofort sichtbar werden, anstatt während des Laufs stillschweigend zu fehlschlagen.
Ordnen Sie Ihre Hoppscotch-Umgebung einer Apidog-Umgebung mit denselben Variablennamen zu. Wenn `staging.json` `base_url` und `api_token` definiert hat, erstellen Sie diese Schlüssel unter der passenden Apidog-Umgebung neu. Wenn Sie die Namen identisch halten, müssen Ihre Testskripte und Anfrage-URLs nicht bearbeitet werden.
Dies ist auch der Moment, in dem sich die Plattformseite auszahlt. Die von Ihnen importierten Endpunkte sind nun Design-Artefakte. Sie können Schemas anhängen, einen Mock-Server daraus generieren und Dokumentationen aus denselben Definitionen veröffentlichen, gegen die Sie testen. Der vollständige Leitfaden zur Apidog CLI deckt die gesamte Oberfläche ab, sobald Sie eingerichtet sind, und der Installationsleitfaden behandelt das Runner-Binary.
Schritt 3: `hopp test` auf `apidog run` mappen
Das mentale Modell lässt sich direkt übertragen. Wo Hoppscotch eine Sammlungsdatei ausführt, führt Apidog ein Testszenario oder eine Sammlung aus Ihrem Projekt aus. Dieselbe Aufgabe, unterschiedliche Quelle der Wahrheit.
# Hoppscotch
hopp test ./collections/checkout-api.json -e ./environments/staging.json
# Apidog
apidog run --access-token $APIDOG_TOKEN -e "Staging"
Beide Befehle führen jede Anfrage der Reihe nach aus, führen Pre-Request-Skripte aus, führen Ihre Test-Assertions aus und geben einen von Null verschiedenen Exit-Code zurück, wenn etwas fehlschlägt. Dieser Exit-Code-Vertrag ist der Teil, auf den CI angewiesen ist, und er bleibt erhalten, sodass sich die Pass/Fail-Logik Ihrer Pipeline nicht ändert.
Die Authentifizierung unterscheidet sich auf nützliche Weise. Hoppscotch übergibt ein persönliches Zugriffstoken mit `--token` für Cloud- oder selbst gehostete Sammlungen. Apidog authentifiziert sich mit einem Login oder einem Zugriffstoken, wodurch die CLI dann auf die Ressourcen in Ihrem Projekt zugreifen kann, anstatt auf eine einzelne exportierte Datei. Wenn Sie schon einmal mit der Token-Behandlung gekämpft haben, erklärt der Authentifizierungs-Walkthrough die Optionen.
Schritt 4: Datengetriebene Läufe konvertieren
Beide Tools unterstützen datengetriebenes Testen, sodass die Iteration über eine CSV-Datei mit Eingaben den Umzug überlebt.
In Hoppscotch übergeben Sie Iterationsdaten und eine Anzahl:
hopp test ./collections/checkout-api.json \
-e ./environments/staging.json \
--iteration-count 50 \
--iteration-data ./data/orders.csv
In Apidog nimmt der Runner einen Datensatz mit `-d` entgegen. Er akzeptiert CSV und JSON, sodass dieselbe `orders.csv` nach dem Import funktioniert:
apidog run --access-token $APIDOG_TOKEN \
-e "Staging" \
-d ./data/orders.csv
Ihre CSV-Headerzeile wird zu den Variablennamen, die Sie in Anfragen und Assertions referenzieren, dasselbe Muster, das Hoppscotch verwendet, sodass die Testkörper nicht neu geschrieben werden müssen. Wenn Sie neu in der Apidog-Variante sind, zeigt der Leitfaden für datengetriebenes Testen, wie Spalten an Variablen gebunden und eine Zeile pro Iteration ausgeführt wird.
Schritt 5: Ihre Reporter konvertieren
Reporting ist der Bereich, in dem die Plattform einen Vorsprung hat, und die Umstellung ist unkompliziert.
Hoppscotch gibt eine JUnit-XML-Datei mit einem Flag aus, die die meisten CI-Systeme für Testpanels parsen:
hopp test ./collections/checkout-api.json \
-e ./environments/staging.json \
--reporter-junit ./reports/results.xml
Apidog bietet Ihnen eine Auswahl an Reportern: eine lesbare CLI-Zusammenfassung, einen HTML-Bericht, den Sie Stakeholdern übergeben können, und einen JSON-Bericht für Maschinen. Sie können Ergebnisse auch in die Cloud pushen, um eine gemeinsame Laufhistorie zu erhalten.
# Menschlich lesbarer HTML-Bericht
apidog run --access-token $APIDOG_TOKEN \
-e "Staging" \
-r html \
--upload-report
Wenn Ihr CI-Dashboard speziell JUnit-XML erwartet, beachten Sie diese Integration während des Wechsels, da Apidog sich eher auf seine CLI-/HTML-/JSON-Reporter sowie Cloud-Berichte als auf ein JUnit-Flag stützt. Für die meisten Teams ist der HTML-Bericht plus hochgeladene Cloud-Historie ein Fortschritt gegenüber einer rohen XML-Datei, die niemand öffnet. Der Leitfaden für Testberichte erklärt jedes Format und wann es verwendet werden sollte.
Vorher und nachher: Befehlszuordnung
| Aufgabe | Hoppscotch CLI | Apidog CLI |
|---|---|---|
| Installation | npm i -g @hoppscotch/cli |
Gemäß dem Installationsleitfaden |
| Sammlung ausführen | hopp test collection.json |
apidog run |
| Umgebung auswählen | -e env.json |
-e "Staging" |
| Auth-Token | --token <pat> |
Login / --access-token |
| Self-hosted / Cloud-Ziel | --server <url> |
Projekt + Zugriffstoken |
| Datengetriebene Eingaben | --iteration-data orders.csv |
-d orders.csv |
| Wiederholte Läufe | --iteration-count 50 |
Iterationsdatensatz |
| Verzögerung zwischen Anfragen hinzufügen | -d <ms> |
Einstellungen pro Szenario |
| JUnit-Bericht | --reporter-junit results.xml |
-r json (oder CLI / HTML) |
| Cloud-Laufhistorie | nicht integriert | --upload-report |
Beachten Sie das `-d`-Flag in dieser Tabelle. In Hoppscotch steht `-d` für die Verzögerung in Millisekunden; in Apidog steht `-d` für den Datensatz für datengetriebene Läufe. Derselbe Buchstabe, unterschiedliche Aufgabe. Das ist der einzige Haken, der Leute beim Wechsel von Hoppscotch zu Apidog stolpern lässt.
Schritt 6: Integration in GitHub Actions
Letzter Schritt, und das Ziel ist ein durchgehend grüner Build. Richten Sie zuerst den Apidog-Job neben dem alten Hoppscotch-Job ein, bestätigen Sie, dass er erfolgreich ist, und löschen Sie dann den alten Schritt. Wechseln Sie niemals blind.
name: API tests
on: [push, pull_request]
jobs:
apidog-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install Apidog CLI
run: npm install -g apidog-cli
- name: Run API tests
env:
APIDOG_TOKEN: ${{ secrets.APIDOG_TOKEN }}
run: |
apidog run \
--access-token "$APIDOG_TOKEN" \
-e "Staging" \
-d ./data/orders.csv \
-r html \
--upload-report
Speichern Sie Ihr Zugriffstoken als Repository-Geheimnis, niemals in der YAML-Datei. Da die CLI bei jeder fehlgeschlagenen Assertion einen Exit-Code ungleich Null zurückgibt, schlägt der Job genau dann fehl, wenn Ihre Tests dies tun, was das Verhalten ist, dem Ihr Team bereits von Hoppscotch vertraut. Der GitHub Actions-Leitfaden behandelt Caching und Matrix-Läufe, und der umfassendere CI/CD-Pipeline-Leitfaden behandelt GitLab, Jenkins und den Rest.
Sobald der Apidog-Job für ein paar Läufe grün ist, entfernen Sie den Hoppscotch-Schritt und dessen npm-Installation. Migration abgeschlossen, Build wurde nie rot.
Ein faires Wort zu Hoppscotch
Nichts davon ist ein Schlag gegen Hoppscotch. Sein CLI-Runner ist schnell und kostenlos, das Projekt ist vollständig Open Source, und Sie können den gesamten Stack selbst hosten. Wenn Sie einen schlanken Runner und nichts weiter wollen, hat er seinen Platz verdient. Der Grund für den Wechsel ist der Umfang: Wenn Design, Mock, Dokumentation und Tests alle eine gemeinsame Definition teilen müssen, kann ein eigenständiger Runner das nicht leisten, eine integrierte Plattform jedoch schon. Vergleichen Sie die beiden Runner direkt in Apidog CLI vs Hoppscotch CLI, und wenn Sie die Anwendungen statt der CLIs abwägen, bieten Postman vs Hoppscotch und die Zusammenfassung der Hoppscotch-Alternativen zusätzlichen Kontext.
