Kostenlose Open Source CLI Tools für API Testing

Die meisten Tutorials zum API-Testen verweisen Sie auf eine GUI. Doch wenn Sie im Terminal arbeiten, Tests in CI ausführen oder ein Tool möchten, dessen Quellcode Sie lesen können, wird das API-Testen auf der Kommandozeile interessant. Open-Source-CLI-Tools bieten Ihnen etwas, das ein gehostetes Produkt nicht kann: eine Lizenz, die Sie prüfen können, eine Binärdatei, die Sie selbst hosten können, und eine Konfigurationsdatei, die Sie zusammen mit Ihrem Code committen können.

Dies ist eine andere Frage als „Was ist das schnellste Tool?“ oder „Was ist die kleinste Binärdatei?“. Hier geht es um Lizenzierung und Kontrolle. Können Sie es in Ihrem eigenen Netzwerk ohne Konto ausführen? Ist der Quellcode auf GitHub unter einer echten, von der OSI genehmigten Lizenz verfügbar? Funktioniert es weiterhin, wenn der Anbieter im nächsten Quartal die Preise ändert? Das sind die Fragen, die diese Liste beantwortet.

Unten finden Sie acht kostenlose, quelloffene CLI-Tools zum Testen von REST-, GraphQL- und HTTP-APIs, jeweils mit ihrer genauen Lizenz, einem echten Installationsbefehl und einem Befehl, der ihre Funktionsweise zeigt. Wenn Sie eine breitere Übersicht wünschen, die auch gehostete Tools umfasst, lesen Sie die Zusammenfassung der besten kostenlosen API-Test-Tools. Für einen rein Terminal-zentrierten Ansatz zum manuellen Aufrufen von Endpunkten behandelt der Leitfaden curl-Alternativen für REST-API-Tests die interaktive Seite.

Was macht ein CLI-Tool für API-Tests „Open Source“?

Viele Tools können kostenlos heruntergeladen werden. Das ist nicht dasselbe wie Open Source. Für diese Liste qualifiziert sich ein Tool nach drei Punkten:

• Eine echte Lizenz. Der Quellcode ist unter einer von der OSI genehmigten Lizenz (MIT, Apache-2.0, MPL-2.0, AGPL-3.0, BSD) öffentlich verfügbar. Sie können ihn lesen, forken und wissen, was Sie tun dürfen.
• Selbst-hostbar, kein Konto. Sie können das gesamte Tool auf Ihrem eigenen Computer oder CI-Runner ausführen, ohne sich für irgendetwas anmelden zu müssen. Keine Kosten pro Benutzer, keine Anforderung einer „Heimruf“-Funktion.
• Gepflegt und überprüfbar. Das Repository befindet sich auf GitHub mit sichtbarer Commit-Historie und Issues, sodass Sie beurteilen können, ob es aktiv ist, bevor Sie eine Pipeline darauf aufbauen.

Jedes der unten aufgeführten Tools erfüllt die ersten beiden Punkte. Ich habe das Tool gekennzeichnet, das den dritten Punkt nicht mehr erfüllt. Die Wahl der Lizenz ist wichtiger, als es scheint: AGPL-3.0 (k6) hat Copyleft-Verpflichtungen, wenn Sie einen Dienst darum herum aufbauen, während MIT und Apache-2.0 permissive Lizenzen sind. Lesen Sie die Lizenz, bevor Sie ein Tool in ein Produkt einbetten.

Hurl: Klartext-HTTP-Tests, eine Rust-Binärdatei

Hurl führt HTTP-Anfragen aus, die in einem Klartextformat geschrieben sind, und überprüft die Antworten. Es wurde von Orange-OpenSource in Rust entwickelt, basiert auf libcurl und wird als einzelne Binärdatei ausgeliefert. Tests lesen sich fast wie die Anfragen selbst, was sie in einem Pull Request leicht überprüfbar macht.

Lizenz: Apache-2.0. Quelle: github.com/Orange-OpenSource/hurl.

brew install hurl   # oder: cargo install --locked hurl

# login.hurl
cat > login.hurl <<'EOF'
POST https://api.example.com/login
{ "user": "acme", "pass": "s3cret" }

HTTP 200
[Asserts]
jsonpath "$.token" exists
EOF

hurl --test login.hurl

Am besten geeignet für: Vertragsähnliche Prüfungen und Smoke-Tests, die Sie als lesbaren Text in der Versionskontrolle speichern möchten. Ehrliche Einschränkung: Es ist HTTP-fokussiert, daher wird es kein gRPC steuern oder Last generieren. Für alles jenseits einfacher Assertionsketten werden Sie mehr .hurl-Dateien schreiben, anstatt eine Skriptsprache zu verwenden.

Step CI: YAML-API-Workflows für CI

Step CI ist ein YAML-konfigurierter Workflow-Runner, der für die kontinuierliche Integration entwickelt wurde. Es deckt REST, GraphQL, gRPC, tRPC und SOAP in einer einzigen Workflow-Datei ab und kann Lasttests durchführen und gegen ein OpenAPI-Schema validieren. Der Runner und das CLI sind dauerhaft kostenlos.

Lizenz: MPL-2.0. Quelle: github.com/stepci/stepci.

npm install -g stepci

# workflow.yml beschreibt Schritte, Prüfungen und Erfassungen
stepci run workflow.yml

Am besten geeignet für: Teams, die eine deklarative Datei wünschen, die einen mehrstufigen API-Flow beschreibt und ihn lokal sowie in CI auf dieselbe Weise ausführt. Ehrliche Einschränkung: MPL-2.0 ist ein schwaches Copyleft, daher müssen Sie Änderungen zurückgeben, wenn Sie Step CIs eigene Dateien modifizieren. Die Verwendung zum Testen Ihrer App bringt keine solche Verpflichtung mit sich.

Schemathesis: Property-basiertes Testen aus Ihrem Schema

Schemathesis liest Ihr OpenAPI- oder GraphQL-Schema und generiert daraus Tausende von Testfällen, indem es eigenschaftsbasiertes Testen verwendet, das auf Pythons Hypothesis-Bibliothek aufbaut. Anstatt jeden Fall selbst zu schreiben, fuzzt es Eingaben, um 500er-Fehler, Schemaverletzungen und Antworten zu finden, die nicht dem entsprechen, was Ihre Dokumentation verspricht.

Lizenz: MIT. Quelle: github.com/schemathesis/schemathesis.

uv pip install schemathesis   # oder: pip install schemathesis

schemathesis run https://api.example.com/openapi.json

Am besten geeignet für: Das Auffinden von Edge-Case-Bugs, für die Sie nie einen Test schreiben würden, besonders vor einer Veröffentlichung. Es ist einer der stärksten Gründe, ein genaues Schema beizubehalten. Ehrliche Einschränkung: Es benötigt ein echtes Schema, um zu funktionieren, und eine große API kann viel Rauschen erzeugen, das Sie mit seinen Hooks und Optionen filtern müssen.

Dredd: Vertragstests gegen Ihre API-Beschreibung

Dredd prüft, ob Ihre Live-API tatsächlich mit ihrem Beschreibungsdokument übereinstimmt. Richten Sie es auf eine OpenAPI- (oder API Blueprint-) Datei und ein laufendes Backend, und es spielt jede dokumentierte Anfrage ab und vergleicht die tatsächliche Antwort mit der Spezifikation. Es ist sprachunabhängig und unterstützt Hooks für Setup und Teardown.

Lizenz: MIT. Quelle: github.com/apiaryio/dredd.

npm install -g dredd

dredd apiary.apib http://127.0.0.1:3000

Am besten geeignet für: Den Nachweis, dass Ihre Dokumentation und Ihre Implementierung nicht auseinandergedriftet sind. Ehrliche Einschränkung, und diese ist real: Das Dredd-Repository wurde im November 2024 archiviert und ist schreibgeschützt. Es funktioniert immer noch, wird aber nicht mehr gepflegt, behandeln Sie es also als ein stabiles Tool ohne zukünftige Fehlerbehebungen. Wenn Sie einen aktiv gepflegten schema-gesteuerten Checker wünschen, ist Schemathesis die sicherere Wahl.

k6: Lasttests in JavaScript geskriptet

k6 ist Grafanas Tool für Last- und Performance-Tests. Sie skripten Tests in JavaScript oder TypeScript, und eine schnelle Go-Engine treibt sie im großen Maßstab an. Es ist die erste Wahl unter den Open-Source-Optionen, wenn Sie wissen müssen, wie sich Ihre API unter Hunderten oder Tausenden von virtuellen Benutzern verhält, nicht nur, ob eine einzelne Anfrage erfolgreich ist.

Lizenz: AGPL-3.0. Quelle: github.com/grafana/k6.

brew install k6

k6 new script.js   # generiert einen Starter-Test
k6 run script.js

Am besten geeignet für: Performance- und Dauerlasttests, die sich im selben Repository wie Ihre Funktionstests befinden. Ehrliche Einschränkung: AGPL-3.0 ist ein starkes Copyleft. Das ist in Ordnung für das Ausführen von Tests, aber wenn Sie einen Dienst um den Code von k6 herum aufbauen und vertreiben, hat die Lizenz echte Verpflichtungen; lesen Sie sie zuerst. k6 konzentriert sich auch auf Last, nicht auf fein abgestufte Vertragsassertions.

Newman: Postman-Sammlungen ohne GUI ausführen

Newman ist Postmans eigener Kommandozeilen-Sammlungs-Runner. Wenn Ihr Team bereits API-Anfragen und Tests als Postman-Sammlung gespeichert hat, führt Newman diese exakte Sammlung vom Terminal oder in CI aus, ohne dass eine Desktop-App erforderlich ist. Es ist der Standardweg, einen Postman-Workflow in eine Pipeline zu integrieren.

Lizenz: Apache-2.0. Quelle: github.com/postmanlabs/newman.

npm install -g newman

newman run my-collection.json -e staging-environment.json

Am besten geeignet für: Teams mit bestehenden Postman-Sammlungen, die CI-Läufe wünschen, ohne für zusätzliche Postman-Lizenzen zu bezahlen. Ehrliche Einschränkung: Es ist an das Postman-Sammlungsformat gebunden, daher erstellen Sie Tests in Postmans UI (oder dessen JSON) und nicht in einer einfachen Konfigurationsdatei. Es führt Sammlungen aus; es entwirft oder mockt keine APIs.

Tavern: API-Tests als pytest-Plugin

Tavern ist eine Python-Bibliothek, ein CLI und ein pytest-Plugin, das API-Tests in YAML beschreibt. Da es sich in pytest integriert, erhalten Sie das gesamte pytest-Ökosystem kostenlos: Fixtures, Berichterstattung, Parallelisierung und CI-Integrationen, die Sie möglicherweise bereits verwenden. Es unterstützt REST, MQTT und gRPC.

Lizenz: MIT. Quelle: github.com/taverntesting/tavern.

pip install tavern

# test_login.tavern.yaml befindet sich neben Ihren anderen Tests
pytest test_login.tavern.yaml

Am besten geeignet für: Python-Entwicklungsteams, die bereits pytest verwenden und API-Tests direkt neben Unit-Tests haben möchten. Ehrliche Einschränkung: Es wird davon ausgegangen, dass Sie mit einem Python-Test-Setup vertraut sind. Wenn Ihr Stack nicht Python ist, stellt die pytest-Abhängigkeit eher eine Reibung als ein Feature dar.

Venom: Multi-Executor-Integrationstests von OVHcloud

Venom von OVHcloud führt Integrationstests über viele Executor-Typen hinweg aus: HTTP-Anfragen, Shell-Skripte, IMAP, Web, Datenbanken und mehr. Es ist in Go geschrieben, verwendet YAML-Testsuiten und generiert xUnit-Ergebnisdateien, die CI-Systeme nativ lesen können. Es glänzt, wenn ein einzelner Test mehr als nur einen HTTP-Endpunkt berühren muss.

Lizenz: BSD (modifiziert). Quelle: github.com/ovh/venom.

# laden Sie die Binärdatei von den GitHub-Releases herunter, dann:
venom run testsuite.yml

Am besten geeignet für: End-to-End-Abläufe, die einen API-Aufruf mit einer Datenbankprüfung oder einem Skriptschritt in einer Testsuite kombinieren. Ehrliche Einschränkung: Bei so vielen Executoren wird der YAML-Code umfangreich, und die Dokumentation geht davon aus, dass Sie Beispiele aus dem Repository zusammensetzen.

Wo Apidog passt (und eine ehrliche Anmerkung)

Hier kommt der ehrliche Teil. Apidog ist kein Open Source. Es ist ein kommerzielles Produkt mit einem kostenlosen Tarif, daher gehört es nicht auf eine Liste quelloffener Tools. Aber es ist aus einem Grund erwähnenswert: Die oben genannten Tools erledigen jeweils eine Aufgabe, und Hurl plus Schemathesis plus Newman plus ein Mock-Server zu einem kohärenten Workflow zusammenzufügen, ist echte Arbeit, die Sie selbst pflegen müssen.

Apidog vereint Design, Testen, Mocking und Dokumentation in einer Plattform, und apidog-cli bringt die Testseite ins Terminal. Sie erstellen Testszenarien einmal und führen sie dann in CI mit einem einzigen Befehl aus:

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run --access-token <TOKEN>   # beendet mit 0 bei Erfolg, ungleich 0 bei Misserfolg

Die Ausgabe ist strukturiertes JSON mit agentHints.nextSteps, was das Skripten oder die Übergabe an einen KI-Agenten erleichtert. Der vollständige apidog-cli Leitfaden erklärt den gesamten Befehlssatz. Also: kein Open Source, aber der kostenlose Tarif plus CLI bietet Ihnen eine integrierte Alternative zum Zusammenfügen mehrerer Einzelzweck-Tools. Wenn eine Lizenz, die Sie prüfen können, eine strenge Anforderung ist, wählen Sie aus den acht oben genannten. Wenn ein integrierter Workflow wichtiger ist, ist dies der Kompromiss.

So wählen Sie aus

Wählen Sie das Tool passend zur Aufgabe. Greifen Sie zu Hurl oder Newman, wenn Sie schnelle, lesbare Anfragenprüfungen wünschen; zu Schemathesis, wenn Sie ein Schema haben und Fehler für Sie gefunden werden sollen; zu k6, wenn es um Skalierung geht; zu Tavern oder Venom, wenn Tests in einer größeren Suite leben müssen. Wenn Sie diese gegen einen größeren Prozess abwägen, deckt der Leitfaden API-Teststrategien ab, wo jeder Typ passt, und der Artikel über headless API-Test-Tools beleuchtet das Ausführen von Tests ganz ohne Benutzeroberfläche.

Zusammenfassung

Open-Source-CLI-Tools bieten Ihnen API-Tests, die Sie lesen, forken und zu Ihren eigenen Bedingungen ausführen können. Hurl und Newman kümmern sich um alltägliche Anfragenprüfungen, Schemathesis und Dredd setzen Ihren Vertrag durch, k6 treibt die Performance an, und Tavern und Venom integrieren API-Tests in größere Suiten. Wählen Sie nach Lizenz und der einen Aufgabe, die Sie erledigen müssen; nichts hindert Sie daran, zwei davon auszuführen.

Wenn Sie lieber Design, Tests, Mocking und Dokumentation an einem Ort erledigen möchten, anstatt eine Toolchain zu pflegen, deckt Apidog den gesamten Lebenszyklus ab und liefert apidog-cli für CI. Laden Sie Apidog herunter, um die CLI neben den oben genannten Tools auszuprobieren und zu sehen, welche Kombination zu Ihrer Pipeline passt.