Outils CLI Open Source Gratuits pour les Tests d'API

La plupart des tutoriels sur les tests d'API vous dirigent vers une interface graphique (GUI). Mais si vous vivez dans le terminal, exécutez des tests en intégration continue (CI), ou souhaitez un outil dont vous pouvez lire le code source, la ligne de commande est l'endroit où les tests d'API deviennent intéressants. Les outils CLI open source vous offrent quelque chose qu'un produit hébergé ne peut pas : une licence que vous pouvez auditer, un binaire que vous pouvez auto-héberger, et un fichier de configuration que vous pouvez commiter à côté de votre code.

C'est une question différente de « quel est l'outil le plus rapide » ou « quel est le binaire le plus petit ». Ici, l'objectif est la licence et le contrôle. Pouvez-vous l'exécuter au sein de votre propre réseau sans compte ? Le code source est-il sur GitHub sous une vraie licence approuvée par l'OSI ? Continuera-t-il à fonctionner si le fournisseur modifie sa tarification le trimestre prochain ? Ce sont les questions auxquelles cette liste répond.

Ci-dessous, vous trouverez huit outils CLI gratuits, dont le code source est disponible, pour tester les API REST, GraphQL et HTTP, chacun avec sa licence exacte, une commande d'installation réelle, et une commande qui montre son fonctionnement. Si vous souhaitez un aperçu plus large incluant des outils hébergés, consultez le récapitulatif des meilleurs outils de test d'API gratuits. Pour une approche purement axée sur le terminal pour interroger des points de terminaison manuellement, le guide sur les alternatives à curl pour les tests d'API REST couvre le côté interactif.

Qu'est-ce qui rend un outil CLI "open source" pour les tests d'API

Beaucoup d'outils sont gratuits à télécharger. Ce n'est pas la même chose que l'open source. Pour cette liste, un outil se qualifie sur trois points :

• Une vraie licence. Le code source est public sous une licence approuvée par l'OSI (MIT, Apache-2.0, MPL-2.0, AGPL-3.0, BSD). Vous pouvez le lire, le forker et savoir ce que vous êtes autorisé à faire.
• Auto-hébergeable, sans compte. Vous pouvez exécuter l'ensemble sur votre propre machine ou un runner CI sans avoir besoin de vous inscrire. Pas de coût par utilisateur, pas d'exigence de communication avec un serveur externe.
• Maintenu et inspectable. Le dépôt est sur GitHub avec un historique de commits et des problèmes visibles, afin que vous puissiez juger s'il est actif avant de construire un pipeline dessus.

Chaque outil ci-dessous remplit les deux premiers critères. J'ai signalé celui qui ne remplit plus le troisième. Le choix de la licence est plus important qu'il n'y paraît : l'AGPL-3.0 (k6) impose des obligations de copyleft si vous construisez un service autour d'elle, tandis que MIT et Apache-2.0 sont permissives. Lisez la licence avant d'intégrer un outil dans un produit.

Hurl : tests HTTP en texte brut, un seul binaire Rust

Hurl exécute des requêtes HTTP écrites dans un format texte brut et effectue des assertions sur les réponses. Il est développé par Orange-OpenSource en Rust, propulsé par libcurl en interne, et livré sous forme d'un unique binaire. Les tests se lisent presque comme les requêtes elles-mêmes, ce qui les rend faciles à revoir dans une pull request.

Licence : Apache-2.0. Source : github.com/Orange-OpenSource/hurl.

brew install hurl   # ou : 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

Idéal pour : les vérifications de type contrat et les tests de fumée que vous souhaitez conserver dans le contrôle de version en tant que texte lisible. Limite honnête : il est axé sur HTTP, donc il ne pilotera pas gRPC ni ne générera de charge. Pour tout ce qui dépasse les chaînes d'assertions simples, vous écrirez plus de fichiers `.hurl` plutôt que d'utiliser un langage de script.

Step CI : workflows d'API YAML conçus pour la CI

Step CI est un exécuteur de workflows configuré en YAML, conçu pour l'intégration continue. Il prend en charge REST, GraphQL, gRPC, tRPC et SOAP dans un seul fichier de workflow, et il peut effectuer des tests de charge et valider par rapport à un schéma OpenAPI. L'exécuteur et le CLI sont gratuits pour toujours.

Licence : MPL-2.0. Source : github.com/stepci/stepci.

npm install -g stepci

# workflow.yml décrit les étapes, les vérifications et les captures
stepci run workflow.yml

Idéal pour : les équipes qui souhaitent un seul fichier déclaratif décrivant un flux d'API multi-étapes et l'exécutant de la même manière localement et en CI. Limite honnête : MPL-2.0 est un copyleft faible, donc si vous modifiez les propres fichiers de Step CI, vous devez partager ces modifications. L'utiliser pour tester votre application n'entraîne aucune obligation de ce type.

Schemathesis : tests basés sur les propriétés à partir de votre schéma

Schemathesis lit votre schéma OpenAPI ou GraphQL et en génère des milliers de cas de test, en utilisant des tests basés sur les propriétés, construits sur la bibliothèque Hypothesis de Python. Au lieu que vous écriviez chaque cas, il « fuzz » les entrées pour trouver des erreurs 500, des violations de schéma et des réponses qui ne correspondent pas à ce que votre documentation promet.

Licence : MIT. Source : github.com/schemathesis/schemathesis.

uv pip install schemathesis   # ou : pip install schemathesis

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

Idéal pour : attraper les bugs de cas extrêmes auxquels vous n'auriez jamais pensé écrire un test, surtout avant une publication. C'est l'une des raisons les plus solides de maintenir un schéma précis. Limite honnête : il a besoin d'un vrai schéma pour fonctionner, et une API volumineuse peut produire beaucoup de bruit que vous voudrez filtrer avec ses hooks et options.

Dredd : tests de contrat par rapport à votre description d'API

Dredd vérifie que votre API en direct correspond réellement à son document de description. Pointez-le vers un fichier OpenAPI (ou API Blueprint) et un backend en cours d'exécution, et il rejouera chaque requête documentée et comparera la réponse réelle à la spécification. Il est indépendant du langage et prend en charge les hooks pour la configuration et le nettoyage.

Licence : MIT. Source : github.com/apiaryio/dredd.

npm install -g dredd

dredd apiary.apib http://127.0.0.1:3000

Idéal pour : prouver que votre documentation et votre implémentation n'ont pas divergé. Limite honnête, et c'est une vraie : le dépôt Dredd a été archivé en novembre 2024 et est en lecture seule. Il fonctionne toujours, mais il n'est plus maintenu, traitez-le donc comme un outil stable sans futures corrections. Si vous voulez un vérificateur basé sur un schéma activement maintenu, Schemathesis est un pari plus sûr.

k6 : tests de charge scriptés en JavaScript

k6 est l'outil de test de charge et de performance de Grafana. Vous écrivez des scripts de test en JavaScript ou TypeScript, et un moteur Go rapide les exécute à grande échelle. C'est l'option open source de référence lorsque vous avez besoin de savoir comment votre API se comporte sous des centaines ou des milliers d'utilisateurs virtuels, et pas seulement si une seule requête passe.

Licence : AGPL-3.0. Source : github.com/grafana/k6.

brew install k6

k6 new script.js   # génère un test de démarrage
k6 run script.js

Idéal pour : les tests de performance et de résilience qui se trouvent dans le même dépôt que vos tests fonctionnels. Limite honnête : l'AGPL-3.0 est un copyleft fort. C'est bien pour exécuter des tests, mais si vous construisez et distribuez un service autour du code de k6, la licence a de réelles obligations ; lisez-la d'abord. k6 se concentre également sur la charge, pas sur des assertions de contrat détaillées.

Newman : exécutez les collections Postman sans l'interface graphique

Newman est l'exécuteur de collections en ligne de commande de Postman. Si votre équipe a déjà des requêtes et des tests d'API enregistrés sous forme de collection Postman, Newman exécute cette collection exacte depuis le terminal ou en CI, sans nécessiter d'application de bureau. C'est la manière standard d'intégrer un workflow Postman dans un pipeline.

Licence : Apache-2.0. Source : github.com/postmanlabs/newman.

npm install -g newman

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

Idéal pour : les équipes ayant des collections Postman existantes qui veulent des exécutions en CI sans payer de sièges Postman supplémentaires. Limite honnête : il est lié au format de collection Postman, vous rédigez donc les tests dans l'interface utilisateur de Postman (ou son JSON) plutôt que dans un fichier de configuration simple. Il exécute des collections ; il ne conçoit ni ne simule des API.

Tavern : tests d'API comme plugin pytest

Tavern est une bibliothèque Python, un CLI et un plugin pytest qui décrit les tests d'API en YAML. Comme il s'intègre à pytest, vous bénéficiez gratuitement de tout l'écosystème pytest : fixtures, rapports, parallélisme et intégrations CI que vous utilisez peut-être déjà. Il gère REST, MQTT et gRPC.

Licence : MIT. Source : github.com/taverntesting/tavern.

pip install tavern

# test_login.tavern.yaml se trouve à côté de vos autres tests
pytest test_login.tavern.yaml

Idéal pour : les entreprises Python qui utilisent déjà pytest et veulent que les tests d'API vivent aux côtés des tests unitaires. Limite honnête : il suppose que vous êtes à l'aise dans une configuration de test Python. Si votre stack n'est pas Python, la dépendance pytest est une contrainte plutôt qu'une fonctionnalité.

Venom : tests d'intégration multi-exécuteurs d'OVHcloud

Venom, d'OVHcloud, exécute des tests d'intégration sur de nombreux types d'exécuteurs : requêtes HTTP, scripts shell, IMAP, web, bases de données, et plus encore. Il est écrit en Go, utilise des suites de tests YAML et émet des fichiers de résultats xUnit que les systèmes CI lisent nativement. Il excelle lorsqu'un seul test doit toucher plus qu'un simple point de terminaison HTTP.

Licence : BSD (modifiée). Source : github.com/ovh/venom.

# téléchargez le binaire depuis les versions GitHub, puis :
venom run testsuite.yml

Idéal pour : les flux de bout en bout qui mélangent un appel d'API avec une vérification de base de données ou une étape de script dans une seule suite de tests. Limite honnête : avec autant d'exécuteurs, le YAML devient verbeux, et la documentation suppose que vous assemblerez des exemples à partir du dépôt.

Où Apidog s'insère (et une note honnête)

Voici la partie honnête. Apidog n'est pas open source. C'est un produit commercial avec un niveau gratuit, il n'a donc pas sa place dans une liste d'outils dont le code source est disponible. Mais il est utile de le connaître pour une raison : les outils ci-dessus font chacun un seul travail, et assembler Hurl plus Schemathesis plus Newman plus un serveur de mock dans un workflow cohérent est un vrai travail que vous devez maintenir vous-même.

Apidog intègre la conception, les tests, le mocking et la documentation dans une seule plateforme, et apidog-cli apporte le côté test au terminal. Vous rédigez les scénarios de test une fois, puis les exécutez en CI avec une seule commande :

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run --access-token <TOKEN>   # retourne 0 en cas de succès, non-zéro en cas d'échec

La sortie est un JSON structuré avec agentHints.nextSteps, ce qui facilite le scriptage ou la transmission à un agent IA. Le guide complet d'apidog-cli parcourt l'ensemble des commandes. Donc : pas open source, mais le niveau gratuit plus le CLI vous offre une alternative intégrée pour connecter plusieurs outils à usage unique. Si une licence que vous pouvez auditer est une exigence stricte, choisissez parmi les huit ci-dessus. Si un workflow intégré est plus important, c'est le compromis.

Comment choisir

Faites correspondre l'outil au travail. Optez pour Hurl ou Newman lorsque vous souhaitez des vérifications de requêtes rapides et lisibles ; Schemathesis lorsque vous avez un schéma et que vous voulez que les bugs soient trouvés pour vous ; k6 lorsque la question est l'échelle ; Tavern ou Venom lorsque les tests doivent s'intégrer dans une suite plus large. Si vous les comparez à un processus plus vaste, le guide des stratégies de test d'API couvre la place de chaque type, et l'article sur les outils de test d'API sans interface graphique examine l'exécution de tests sans aucune UI.

En résumé

Les outils CLI open source vous offrent des tests d'API que vous pouvez lire, forker et exécuter selon vos propres termes. Hurl et Newman gèrent les vérifications de requêtes quotidiennes, Schemathesis et Dredd appliquent votre contrat, k6 met l'accent sur la performance, et Tavern et Venom intègrent les tests d'API dans des suites plus larges. Choisissez par licence et par la tâche spécifique que vous devez accomplir ; rien ne vous empêche d'en exécuter deux.

Lorsque vous préférez concevoir, tester, simuler et documenter en un seul endroit plutôt que de maintenir une chaîne d'outils, Apidog couvre l'intégralité du cycle de vie et fournit apidog-cli pour la CI. Téléchargez Apidog pour essayer le CLI en parallèle des outils ci-dessus et voir quelle combinaison correspond à votre pipeline.