L'interface de ligne de commande (CLI) de Hoppscotch est un moyen gratuit et open-source d'exécuter des collections d'API depuis un terminal. Si vous utilisez déjà Hoppscotch sur le web ou le bureau, hopp test vous permet d'intégrer ces mêmes requêtes dans un pipeline CI sans rien payer. C'est une véritable force, et cet article ne prétend pas le contraire.
Mais l'interface CLI de Hoppscotch est aussi délibérément limitée. Elle exécute des collections et rapporte les résultats. Elle ne conçoit pas les API, ne les simule pas, ne les documente pas et ne les gère pas comme du code. De nombreuses équipes en arrivent donc à vouloir un seul outil qui fait plus que d'exécuter un fichier JSON, ou elles rencontrent un point de friction comme l'exigence de Node v22 et commencent à chercher des alternatives.
Ce que l'interface CLI de Hoppscotch fait réellement
L'interface CLI de Hoppscotch est distribuée sous forme de package npm @hoppscotch/cli. Vous l'installez globalement :
npm i -g @hoppscotch/cli
Une chose à savoir d'emblée : elle nécessite Node.js v22 ou une version plus récente. Si vous êtes bloqué sur Node 20, vous restez sur la CLI v0.26.0, ce qui peut compliquer une image CI partagée où d'autres tâches épinglent une version plus ancienne de Node.
La commande principale est hopp test. Vous la pointez vers un fichier de collection (ou un ID de collection cloud) et elle exécute chaque requête dans l'ordre :
hopp test ./collection.json -e ./environment.json -d 500
Pour les instances cloud ou auto-hébergées, vous passez un ID et des identifiants :
hopp test <collection-id> -e <environment-id> --token <access_token> --server <server-url>
Elle exécute les scripts de pré-requête et les scripts de test (suites pw.test(), cas pw.expect()), valide les réponses et se termine avec un code non nul si une assertion échoue. Elle prend également en charge --reporter-junit <chemin> pour le format JUnit XML, ainsi que --iteration-count et --iteration-data <csv> pour les exécutions basées sur les données. C'est un runner gratuit réellement performant.
Pourquoi les équipes recherchent une alternative à hopp test
Les raisons pour lesquelles les gens recherchent un remplacement à l'interface CLI de Hoppscotch sont généralement pratiques, et non idéologiques :
- C'est un runner de collections, rien de plus. La conception, le mocking et la documentation résident ailleurs. Vous finissez par assembler plusieurs outils.
- Vous devez d'abord exporter le JSON. Les spécifications et les environnements sont importés sous forme de fichiers de collection/environnement exportés (ou d'IDs cloud). Il n'y a pas de linting de spécifications ou de couche de conception dans l'interface CLI elle-même.
- La base Node v22. Plus récent que la valeur par défaut de nombreuses images de build, ce qui implique une jonglerie supplémentaire avec les versions.
- Pas de workflow "spec-as-code". Vous ne pouvez pas gérer les endpoints, les schémas ou les branches depuis la CLI. La CLI est en aval de l'endroit où vous avez défini l'API.
Rien de tout cela ne rend Hoppscotch mauvais. Cela en fait un outil ciblé. Si vous souhaitez une couverture plus large, voici les alternatives qui méritent votre attention.
1. Apidog CLI (la meilleure alternative tout-en-un)
Apidog est une plateforme API tout-en-un qui couvre la conception, le débogage, le mocking, la documentation et les tests. L'interface CLI d'Apidog intègre les aspects de test et de gestion des ressources dans le terminal et le CI/CD, ce qui en fait une alternative solide à un runner de collections autonome.
Avec apidog run, vous exécutez des scénarios de test et des collections depuis la ligne de commande. Il prend en charge les tests basés sur les données via -d (ensembles de données CSV ou JSON), les environnements via -e, les reporters aux formats CLI, HTML et JSON, et les rapports de test cloud avec --upload-report. Au-delà de l'exécution des tests, la CLI peut importer OpenAPI et gérer les ressources API, les endpoints, les schémas, les environnements, les branches et les requêtes de fusion, en tant que code. Ainsi, votre définition d'API et vos tests vivent dans le même système au lieu d'être exportés en va-et-vient.
Pour être précis sur la portée : Apidog valide les spécifications lors de l'importation, mais il ne fournit pas de linter OpenAPI autonome ni de commande split/join/bundle. Si le linting pur des spécifications en CI est votre objectif, inso (voir ci-dessous) est plus approprié. L'approche d'Apidog est l'intégration : vous concevez, simulez, documentez et testez au même endroit, puis pilotez les couches de test et de ressources depuis la CLI.
Avantages :
- Une seule plateforme pour la conception, le mocking, la documentation et les tests au lieu d'une chaîne d'outils
- Exécutions basées sur les données avec des ensembles de données CSV/JSON
- Rapporteurs CLI, HTML et JSON, plus des rapports cloud téléchargeables
- Ressource en tant que code : gérez les endpoints, les schémas, les branches et les requêtes de fusion depuis la CLI
- Importe directement OpenAPI
Inconvénients :
- Pas de commande de linter de spécifications autonome (utilisez inso ou Redocly pour le linting de style Spectral)
- La plateforme complète est plus que ce dont vous avez besoin si vous n'exécutez qu'une seule collection
Si vous comparez les deux directement, consultez Apidog CLI vs Hoppscotch CLI et le guide pratique migrer de Hoppscotch CLI vers Apidog CLI. Le guide complet d'Apidog CLI couvre l'installation, l'authentification et l'ensemble des commandes. Pour l'essayer, téléchargez Apidog.
2. Newman (le runner de Postman)
Newman est le runner de collections officiel en ligne de commande de Postman. Si votre équipe utilise déjà Postman, Newman est le chemin de moindre résistance : exportez la collection et l'environnement, puis exécutez-les en CI.
newman run collection.json -e env.json -r cli,json
Il prend en charge plusieurs reporters (CLI, JSON, JUnit, HTML via un plugin), des fichiers de données pour l'itération et un contrat de code de sortie stable pour les pipelines.
Avantages :
- Mature, largement documenté, vaste écosystème
- Compatibilité Postman de premier ordre
- Rapporteurs flexibles et itérations basées sur les données
Inconvénients :
- Comme Hoppscotch CLI, c'est seulement un runner, sans couche de conception ou de documentation
- Lié au format de collection Postman et à son modèle de script
- Vous devez toujours exporter le JSON pour l'utiliser
Pour une comparaison directe avec l'approche Apidog, consultez Apidog CLI vs Newman.
3. inso (CLI d'Insomnia par Kong)
inso est le compagnon en ligne de commande du client Insomnia open-source de Kong. Il fait quelque chose que Hoppscotch CLI ne fait pas : il vérifie la conformité (lint) des spécifications OpenAPI. Le linting s'exécute sur Spectral, le linter OpenAPI de Stoplight, donc si les validations de qualité des spécifications en CI sont importantes pour vous, inso est un véritable concurrent.
inso run test "My Test Suite" --env "Staging"
inso lint spec "My API Design"
inso export spec "My API Design" --output output.yaml
inso lit à partir d'un répertoire .insomnia (créé par Git Sync d'Insomnia) ou du répertoire de données de l'application, et référence les suites et les spécifications par leur nom. Vous pouvez l'installer avec brew install inso ou docker pull kong/inso:latest.
Avantages :
- Linting OpenAPI réel via Spectral
- Exécute les tests et les collections, exporte les spécifications, le tout depuis le terminal
- Chemins d'installation Brew et Docker
Inconvénients :
- Référence les ressources par leur nom, ce qui peut être fragile dans les scripts
- Insomnia 8 a introduit un compte cloud/login obligatoire en 2023, ce qui a provoqué des réactions négatives, et il y a eu des incidents de migration et de perte de données liés à ce changement. Il est bon de le savoir si vous adoptez l'écosystème récemment.
Si vous évaluez Insomnia plus largement, Apidog vs Insomnia et les meilleures alternatives à l'application Insomnia sont de bonnes lectures à suivre. Il existe également une comparaison ciblée Apidog CLI vs inso (Insomnia CLI).
4. Step CI (tests API open-source en YAML)
Step CI est un outil open-source de qualité API qui définit les tests en YAML déclaratif plutôt qu'en JS scripté. Vous décrivez la requête et la réponse attendue, et il les vérifie. Il prend en charge REST, GraphQL et gRPC, ce qui représente une couverture de protocole plus large que la plupart des runners de collections.
npx stepci run workflow.yml
Avantages :
- YAML déclaratif, facile à lire dans le contrôle de version
- Multi-protocole (REST, GraphQL, gRPC)
- Pas de dépendance GUI, la configuration réside entièrement dans votre dépôt
Inconvénients :
- Communauté et écosystème plus petits
- Pas de couche de conception, de mocking ou de documentation
- Vous écrivez les tests manuellement en YAML plutôt que de les enregistrer
Step CI est une bonne option si vous souhaitez des tests git-natifs et lisibles par l'homme, et que vous n'avez pas du tout besoin d'une interface utilisateur.
5. Hurl (tests HTTP en texte brut)
Hurl exécute des requêtes HTTP écrites dans un format texte brut simple et effectue des assertions sur les réponses. Il est basé sur libcurl, s'exécute rapidement et produit une sortie propre. Il n'y a pas de scripts ni de collections JSON, juste des fichiers .hurl que vous pouvez comparer (diff) dans une pull request.
GET https://api.example.com/health
HTTP 200
[Asserts]
jsonpath "$.status" == "up"
Exécutez-le avec :
hurl --test health.hurl
Avantages :
- Extrêmement léger, binaire unique, rapide
- Fichiers texte brut qui se lisent comme de la documentation
- Idéal pour les tests de fumée et les vérifications de santé en CI
Inconvénients :
- Niveau inférieur à celui d'un framework de test complet
- Pas de fonctionnalités de conception, de mocking ou de documentation
- Moins pratique pour les scénarios complexes, chaînés et basés sur les données
Hurl excelle pour les vérifications de contrats et les tests de fumée rapides et lisibles. Il n'essaie pas d'être une plateforme.
Tableau comparatif
| Outil | Licence | Objectif principal | Basé sur les données | Linting de spécifications | Conception/mocking/docs | Formats de rapport |
|---|---|---|---|---|---|---|
| Apidog CLI | Commercial (plan gratuit) | Plateforme complète + tests CLI | Oui (CSV/JSON) | Non (valide à l'importation) | Oui | CLI, HTML, JSON, cloud |
| Hoppscotch CLI | Open source | Runner de collections | Oui (itérations CSV) | Non | Non | CLI, JUnit |
| Newman | Open source | Runner Postman | Oui (fichiers de données) | Non | Non | CLI, JSON, JUnit, HTML |
| inso | Open source | Runner Insomnia + linter | Limité | Oui (Spectral) | Partiel (docs de conception) | CLI, JUnit |
| Step CI | Open source | Tests API YAML | Oui | Non | Non | CLI, JUnit |
| Hurl | Open source | Tests HTTP texte brut | Via le templating | Non | Non | CLI, JUnit, HTML |
Comment choisir
- Vous voulez un seul outil de la conception aux tests : Apidog CLI. Il élimine la danse d'exportation-JSON-puis-exécution et maintient vos ressources API et vos tests dans le même système.
- Votre équipe utilise déjà Postman : Newman. Coût de commutation le plus faible.
- Vous avez besoin du linting OpenAPI en CI : inso, grâce à Spectral.
- Vous voulez des tests déclaratifs, natifs de Git : Step CI (YAML) ou Hurl (texte brut).
- Vous êtes satisfait d'un runner OSS gratuit et voulez juste vous affranchir de Node 22 : l'un des outils ci-dessus, car Newman, Step CI et Hurl ne partagent pas cette exigence.
Si votre principale raison de changer est le plafond du runner de collections plutôt qu'un inconvénient particulier, la voie intégrée est celle à examiner en premier. Consultez Apidog CLI vs Postman CLI et pipeline CI/CD d'Apidog CLI pour voir comment la partie test s'intègre dans un véritable pipeline, et rapports de test d'Apidog CLI pour les options de rapport.
FAQ
L'interface CLI de Hoppscotch est-elle gratuite ? Oui. @hoppscotch/cli est open source et gratuit à utiliser. Il exécute des collections, des scripts de test et génère des rapports JUnit. Les alternatives présentées ici ne concernent pas le coût de Hoppscotch, mais le désir d'avoir plus qu'un simple runner.
Quelle est l'alternative la plus simple à Hoppscotch CLI si je ne veux pas de Node v22 ? Hurl est un binaire unique sans aucune dépendance Node. inso s'installe via Homebrew ou Docker. Step CI s'exécute via npx mais n'est pas lié à Node 22 de la même manière que l'actuelle Hoppscotch CLI.
Puis-je déplacer mes collections Hoppscotch existantes vers un autre outil ? Oui. La plupart des outils acceptent les collections exportées ou OpenAPI. Pour la voie intégrée, le guide migrer de Hoppscotch CLI vers Apidog CLI explique comment importer et réexécuter vos suites.
Apidog CLI vérifie-t-il les spécifications OpenAPI comme inso ? Non. Apidog valide les spécifications lors de l'importation mais n'a pas de commande de linter autonome. Si l'application d'un guide de style de type Spectral en CI est une exigence stricte, associez Apidog à inso ou utilisez Apidog CLI vs Redocly CLI pour comparer l'option axée sur le linting.
Quelle alternative est la meilleure pour un pipeline CI ? Toutes renvoient des codes de sortie non nuls en cas d'échec, donc toutes fonctionnent en CI. Le facteur décisif est ce dont vous avez besoin : les exécutions pures favorisent Newman ou Hurl ; une source unique de vérité pour la conception et les tests favorise Apidog CLI ; les validations de spécifications favorisent inso.
L'interface CLI de Hoppscotch fait bien son unique travail. Si c'est tout ce dont vous avez besoin, restez-y. Si vous préférez fusionner la conception, le mocking, la documentation et les tests dans un seul flux de travail plutôt que de connecter des runners, une plateforme intégrée est la solution. Commencez par le guide complet d'Apidog CLI, puis téléchargez Apidog et exécutez votre premier scénario.