Die Hoppscotch CLI ist eine kostenlose Open-Source-Möglichkeit, API-Sammlungen von einem Terminal aus auszuführen. Wenn Sie Hoppscotch bereits im Web oder auf dem Desktop verwenden, können Sie mit hopp test dieselben Anfragen in eine CI-Pipeline integrieren, ohne dafür bezahlen zu müssen. Das ist eine echte Stärke, und dieser Artikel wird nicht so tun, als wäre es anders.
Die Hoppscotch CLI ist aber auch bewusst eingeschränkt. Sie führt Sammlungen aus und liefert Berichte über die Ergebnisse. Sie entwirft keine APIs, mockt sie nicht, dokumentiert sie nicht und verwaltet sie nicht als Code. Viele Teams erreichen daher einen Punkt, an dem sie ein einziges Tool wünschen, das mehr kann, als nur eine JSON-Datei auszuführen, oder sie stoßen auf einen Reibungspunkt wie die Node v22-Anforderung und sehen sich nach Alternativen um.
Was die Hoppscotch CLI tatsächlich leistet
Die Hoppscotch CLI wird als npm-Paket @hoppscotch/cli ausgeliefert. Sie installieren es global:
npm i -g @hoppscotch/cli
Eines vorab: Es benötigt Node.js v22 oder neuer. Wenn Sie an Node 20 festhalten, bleiben Sie bei CLI v0.26.0, was ein gemeinsames CI-Image komplizieren kann, bei dem andere Jobs eine ältere Node-Version festlegen.
Der Kernbefehl ist hopp test. Sie weisen ihn auf eine Sammlungsdatei (oder eine Cloud-Sammlungs-ID) und er führt jede Anfrage der Reihe nach aus:
hopp test ./collection.json -e ./environment.json -d 500
Für Cloud- oder selbst gehostete Instanzen übergeben Sie eine ID plus Anmeldeinformationen:
hopp test <collection-id> -e <environment-id> --token <access_token> --server <server-url>
Es führt Pre-Request-Skripte und Testskripte (pw.test() Suiten, pw.expect() Fälle) aus, validiert Antworten und beendet den Prozess mit einem Nicht-Null-Code, wenn eine Assertion fehlschlägt. Es unterstützt auch --reporter-junit <path> für JUnit XML, sowie --iteration-count und --iteration-data <csv> für datengesteuerte Läufe. Das ist ein wirklich leistungsfähiger kostenloser Runner.
Warum Teams nach einer hopp test Alternative suchen
Die Gründe, warum Menschen nach einem Ersatz für die Hoppscotch CLI suchen, sind meist praktischer Natur, nicht ideologisch:
- Es ist ein Sammlungs-Runner, mehr nicht. Design, Mocking und Dokumentation befinden sich woanders. Man fügt letztendlich mehrere Tools zusammen.
- Man muss zuerst JSON exportieren. Spezifikationen und Umgebungen werden als exportierte Sammlungs-/Umgebungsdateien (oder Cloud-IDs) importiert. Es gibt kein Spec-Linting oder eine Design-Ebene in der CLI selbst.
- Die Node v22-Untergrenze. Neuer als der Standard vieler Build-Images, was zusätzliche Versionsverwaltung bedeutet.
- Kein Spec-as-Code-Workflow. Man kann Endpunkte, Schemata oder Branches nicht über die CLI verwalten. Die CLI ist nachgeschaltet dessen, wo Sie die API definiert haben.
Nichts davon macht Hoppscotch schlecht. Es macht es zu einem fokussierten Tool. Wenn Sie eine breitere Abdeckung wünschen, finden Sie hier die Alternativen, die Ihre Zeit wert sind.
1. Apidog CLI (beste All-in-One-Alternative)
Apidog ist eine All-in-One-API-Plattform, die Design, Debugging, Mocking, Dokumentation und Tests abdeckt. Die Apidog CLI bringt die Test- und Ressourcenverwaltungsseite ins Terminal und in CI/CD, was sie zu einer starken Alternative zu einem eigenständigen Collection Runner macht.
Mit apidog run führen Sie Testszenarien und Sammlungen über die Befehlszeile aus. Es unterstützt datengesteuerte Tests über -d (CSV- oder JSON-Datensätze), Umgebungen über -e, Reporter in CLI-, HTML- und JSON-Formaten sowie Cloud-Testberichte mit --upload-report. Neben dem Ausführen von Tests kann die CLI OpenAPI importieren und API-Ressourcen, Endpunkte, Schemata, Umgebungen, Branches und Merge-Anfragen als Code verwalten. So leben Ihre API-Definition und Ihre Tests im selben System, anstatt hin- und her exportiert zu werden.
Um den Umfang genau zu beschreiben: Apidog validiert Spezifikationen beim Import, liefert aber keinen eigenständigen OpenAPI-Linter oder einen split/join/bundle-Befehl mit. Wenn reines Spec-Linting in CI Ihr Ziel ist, ist inso (siehe unten) die bessere Wahl. Apidogs Ansatz ist Integration: Sie entwerfen, mocken, dokumentieren und testen an einem Ort und steuern dann die Test- und Ressourcenebenen über die CLI.
Vorteile:
- Eine Plattform für Design, Mock, Docs und Tests anstelle einer Toolchain
- Datengesteuerte Ausführungen mit CSV/JSON-Datensätzen
- CLI-, HTML- und JSON-Reporter sowie hochladbare Cloud-Berichte
- Ressourcen als Code: Endpunkte, Schemata, Branches und Merge-Anfragen über die CLI verwalten
- Importiert OpenAPI direkt
Nachteile:
- Kein eigenständiger Spec-Linter-Befehl (verwenden Sie inso oder Redocly für Spectral-basiertes Linting)
- Die vollständige Plattform ist mehr, als Sie brauchen, wenn Sie nur eine Sammlung ausführen
Wenn Sie die beiden direkt vergleichen möchten, lesen Sie Apidog CLI vs Hoppscotch CLI und die praktische Anleitung zur Migration von Hoppscotch CLI zu Apidog CLI. Der umfassendere Apidog CLI Complete Guide behandelt Installation, Authentifizierung und den gesamten Befehlssatz. Um es auszuprobieren, laden Sie Apidog herunter.
2. Newman (der Postman-Runner)
Newman ist der offizielle Befehlszeilen-Collection-Runner von Postman. Wenn Ihr Team bereits mit Postman arbeitet, ist Newman der Weg des geringsten Widerstands: Exportieren Sie die Collection und die Umgebung und führen Sie sie dann in CI aus.
newman run collection.json -e env.json -r cli,json
Es unterstützt mehrere Reporter (CLI, JSON, JUnit, HTML über ein Plugin), Datendateien für Iterationen und einen stabilen Exit-Code-Vertrag für Pipelines.
Vorteile:
- Ausgereift, umfassend dokumentiert, riesiges Ökosystem
- Erstklassige Postman-Kompatibilität
- Flexible Reporter und datengesteuerte Iterationen
Nachteile:
- Wie Hoppscotch CLI ist es nur ein Runner, keine Design- oder Docs-Ebene
- Gebunden an das Postman-Collection-Format und sein Skripting-Modell
- Man exportiert immer noch JSON, um es zu verwenden
Für einen direkten Vergleich mit dem Apidog-Ansatz siehe Apidog CLI vs Newman.
3. inso (Insomnia CLI von Kong)
inso ist der Befehlszeilen-Begleiter des Open-Source-Insomnia-Clients von Kong. Es kann etwas, was die Hoppscotch CLI nicht kann: Es lintet OpenAPI-Spezifikationen. Das Linting basiert auf Spectral, dem Stoplight OpenAPI Linter, wenn Ihnen also Spec Quality Gates in CI wichtig sind, ist inso ein ernstzunehmender Kandidat.
inso run test "My Test Suite" --env "Staging"
inso lint spec "My API Design"
inso export spec "My API Design" --output output.yaml
inso liest aus einem .insomnia-Verzeichnis (erstellt durch Insomnias Git Sync) oder dem App-Datenverzeichnis und referenziert Suiten und Specs anhand ihres Namens. Sie können es mit brew install inso oder docker pull kong/inso:latest installieren.
Vorteile:
- Echtes OpenAPI-Linting über Spectral
- Tests und Sammlungen ausführen, Spezifikationen exportieren – alles vom Terminal aus
- Installationswege über Brew und Docker
Nachteile:
- Referenziert Ressourcen nach Namen, was in Skripten anfällig sein kann
- Insomnia 8 führte 2023 ein obligatorisches Cloud-/Login-Konto ein, was zu Gegenwind führte, und es gab Migrations- und Datenverlustvorfälle im Zusammenhang mit dieser Änderung. Gut zu wissen, wenn Sie das Ökosystem neu einführen.
Wenn Sie Insomnia umfassender bewerten, sind Apidog vs Insomnia und die besten Insomnia App Alternativen gute nächste Lektüren. Es gibt auch einen detaillierten Vergleich zwischen Apidog CLI und inso (Insomnia CLI).
4. Step CI (Open-Source-API-Tests in YAML)
Step CI ist ein Open-Source-Tool für API-Qualität, das Tests in deklarativem YAML anstelle von geskriptetem JS definiert. Sie beschreiben die Anfrage und die erwartete Antwort, und es überprüft diese. Es unterstützt REST, GraphQL und gRPC, was eine breitere Protokollabdeckung ist als bei den meisten Collection Runnern.
npx stepci run workflow.yml
Vorteile:
- Deklaratives YAML, leicht in der Versionskontrolle zu lesen
- Multi-Protokoll (REST, GraphQL, gRPC)
- Keine GUI-Abhängigkeit, Konfiguration lebt vollständig in Ihrem Repo
Nachteile:
- Kleinere Community und kleineres Ökosystem
- Keine Design-, Mock- oder Dokumentationsschicht
- Man schreibt Tests manuell in YAML, anstatt sie aufzuzeichnen
Step CI ist eine gute Wahl, wenn Sie git-native, menschenlesbare Tests wünschen und überhaupt keine Benutzeroberfläche benötigen.
5. Hurl (Klartext-HTTP-Tests)
Hurl führt HTTP-Anfragen aus, die in einem einfachen Klartextformat geschrieben sind, und prüft die Antworten. Es basiert auf libcurl, ist schnell und erzeugt eine saubere Ausgabe. Es gibt keine Skripte und keine JSON-Sammlungen, nur .hurl-Dateien, die Sie in einem Pull Request vergleichen können.
GET https://api.example.com/health
HTTP 200
[Asserts]
jsonpath "$.status" == "up"
Ausführen mit:
hurl --test health.hurl
Vorteile:
- Extrem leichtgewichtig, einzelne Binärdatei, schnell
- Klartextdateien, die wie Dokumentation lesbar sind
- Ideal für Smoke-Tests und Health Checks in CI
Nachteile:
- Niedrigeres Niveau als ein vollständiges Test-Framework
- Keine Design-, Mock- oder Dokumentationsfunktionen
- Weniger praktisch für komplexe, verkettete, datengesteuerte Szenarien
Hurl glänzt bei schnellen, lesbaren Vertrags- und Smoke-Checks. Es versucht nicht, eine Plattform zu sein.
Vergleichstabelle
| Tool | Lizenz | Kernfokus | Datengesteuert | Spec-Linting | Design/Mock/Dokumentation | Berichtsformate |
|---|---|---|---|---|---|---|
| Apidog CLI | Kommerziell (kostenlose Stufe) | Volle Plattform + CLI-Tests | Ja (CSV/JSON) | Nein (validiert beim Import) | Ja | CLI, HTML, JSON, Cloud |
| Hoppscotch CLI | Open Source | Sammlungs-Runner | Ja (CSV-Iterationen) | Nein | Nein | CLI, JUnit |
| Newman | Open Source | Postman-Runner | Ja (Datendateien) | Nein | Nein | CLI, JSON, JUnit, HTML |
| inso | Open Source | Insomnia-Runner + Linter | Begrenzt | Ja (Spectral) | Teilweise (Design-Dokumente) | CLI, JUnit |
| Step CI | Open Source | YAML-API-Tests | Ja | Nein | Nein | CLI, JUnit |
| Hurl | Open Source | Klartext-HTTP-Tests | Via Templating | Nein | Nein | CLI, JUnit, HTML |
Wie man wählt
- Sie möchten ein einziges Tool für Design bis zum Testen: Apidog CLI. Es eliminiert das Export-JSON-und-dann-Ausführen-Prozedere und hält Ihre API-Ressourcen und Tests im selben System.
- Ihr Team verwendet bereits Postman: Newman. Geringste Umstellungskosten.
- Sie benötigen OpenAPI-Linting in CI: inso, wegen Spectral.
- Sie wünschen sich git-native, deklarative Tests: Step CI (YAML) oder Hurl (Klartext).
- Sie sind mit einem kostenlosen OSS-Runner zufrieden und möchten nur von Node 22 weg: jede der oben genannten, da Newman, Step CI und Hurl diese Anforderung nicht teilen.
Wenn Ihr Hauptgrund für den Wechsel die Einschränkung des Collection Runners ist und nicht eine einzelne Unannehmlichkeit, sollten Sie zuerst die integrierte Lösung in Betracht ziehen. Siehe Apidog CLI vs Postman CLI und Apidog CLI CI/CD pipeline, um zu sehen, wie die Testseite in eine echte Pipeline passt, und Apidog CLI test reports für die Reporteroptionen.
FAQ
Ist die Hoppscotch CLI kostenlos? Ja. @hoppscotch/cli ist Open Source und kostenlos nutzbar. Es führt Sammlungen aus, führt Testskripte aus und erstellt JUnit-Berichte. Die hier genannten Alternativen handeln nicht davon, dass Hoppscotch teuer ist, sondern davon, dass man mehr als nur einen Runner möchte.
Was ist die einfachste Alternative zur Hoppscotch CLI, wenn ich Node v22 nicht möchte? Hurl ist eine einzelne Binärdatei ohne Node-Abhängigkeit. inso wird über Homebrew oder Docker installiert. Step CI läuft über npx, ist aber nicht an Node 22 gebunden, wie es bei der aktuellen Hoppscotch CLI der Fall ist.
Kann ich meine bestehenden Hoppscotch-Sammlungen in ein anderes Tool verschieben? Ja. Die meisten Tools akzeptieren exportierte Sammlungen oder OpenAPI. Für den integrierten Weg führt der Leitfaden zur Migration von Hoppscotch CLI zu Apidog CLI durch den Import und das erneute Ausführen Ihrer Suiten.
Lintet Apidog CLI OpenAPI-Spezifikationen wie inso? Nein. Apidog validiert Spezifikationen beim Import, hat aber keinen eigenständigen Linter-Befehl. Wenn die Durchsetzung von Spectral-basierten Style-Guides in CI eine strenge Anforderung ist, kombinieren Sie Apidog mit inso oder verwenden Sie Apidog CLI vs Redocly CLI, um die linter-fokussierte Option zu vergleichen.
Welche Alternative ist am besten für eine CI-Pipeline? Alle geben bei Misserfolg einen Nicht-Null-Exit-Code zurück, sodass alle in CI funktionieren. Der entscheidende Faktor ist, was Sie sonst noch benötigen: reine Ausführungen bevorzugen Newman oder Hurl; eine einzige Quelle der Wahrheit für Design und Tests bevorzugt Apidog CLI; Spec Gates bevorzugen inso.
Die Hoppscotch CLI erledigt ihre eine Aufgabe gut. Wenn diese eine Aufgabe alles ist, was Sie brauchen, bleiben Sie dabei. Wenn Sie Design, Mocking, Dokumentation und Tests lieber in einem einzigen Workflow zusammenführen möchten, anstatt Runner miteinander zu verbinden, ist eine integrierte Plattform der richtige Schritt. Beginnen Sie mit dem Apidog CLI Complete Guide, laden Sie dann Apidog herunter und führen Sie Ihr erstes Szenario aus.