Apidog CLI vs inso (Insomnia CLI) : Quel outil de tests API pour l'intégration continue ?

Le choix d'un lanceur de tests CLI pour votre pipeline se résume à une question simple : qu'est-ce qui exécute déjà vos API en développement, et qu'avez-vous besoin d'automatiser en CI ? Si votre équipe utilise Insomnia, inso est le compagnon évident. Si vous voulez une plateforme unique qui conçoit, simule, documente et teste, l'interface CLI Apidog change la donne.

Ce que chaque outil est

inso est le compagnon en ligne de commande d'Insomnia, le client API open-source de Kong. Il apporte trois choses au terminal et à la CI : l'exécution de collections de requêtes, l'exécution de suites de tests unitaires et le linting des spécifications OpenAPI. Il lit les mêmes données que celles utilisées par votre application de bureau Insomnia, donc si vous construisez des requêtes dans l'interface graphique, inso les exécute sans interface graphique (headless).

Apidog CLI est le lanceur de terminal pour Apidog, une plateforme API tout-en-un qui couvre la conception, le débogage, la simulation, la documentation et les tests dans un seul espace de travail. L'interface CLI exécute des scénarios de test et des collections à partir d'un projet, prend en charge les exécutions basées sur les données et génère des rapports dans plusieurs formats. Elle peut également importer OpenAPI et gérer les ressources API comme les points de terminaison, les schémas et les branches en tant que code.

La différence fondamentale apparaît avant même d'exécuter un seul test. inso est un lanceur ciblé, plus un linter pour l'écosystème Insomnia. Apidog CLI est la surface de test d'une plateforme plus large.

Apidog CLI vs inso : le tableau comparatif

Le tableau est la version courte. Les sections ci-dessous expliquent les différences qui comptent réellement lorsque vous intégrez l'un ou l'autre dans votre CI.

Installation : brew et Docker vs l'installateur Apidog

inso est distribué via plusieurs canaux documentés. Les plus courants :

# Homebrew
brew install inso

# Docker
docker pull kong/inso:latest

Il existe également des téléchargements directs pour Windows, Linux et macOS. Historiquement, inso était sur npm sous le nom insomnia-inso, mais Homebrew, Docker et les téléchargements directs sont les chemins que Kong documente aujourd'hui. L'image Docker est pratique pour les exécuteurs CI où vous ne voulez pas gérer une chaîne d'outils Node.

Apidog CLI s'installe depuis la page de téléchargement d'Apidog et exécute des scénarios qui se trouvent dans votre projet Apidog. Étant donné que les tests sont liés au projet, l'interface CLI extrait la définition actuelle plutôt que de lire un dossier local que vous devriez synchroniser manuellement. Si vous souhaitez un guide complet, le guide d'installation d'Apidog CLI et le guide complet de l'interface CLI couvrent l'ensemble de la configuration.

Ce que chacun exécute et d'où il lit

C'est la plus grande divergence pratique dans la décision Apidog CLI vs Insomnia CLI.

inso référence les suites et les spécifications par nom. Vous le dirigez vers un document de conception ou une collection par son nom d'affichage, et il trouve la définition dans un répertoire .insomnia de votre répertoire de travail (créé par la synchronisation Git d'Insomnia) ou dans le répertoire de données de l'application Insomnia si l'application est installée. Vous pouvez remplacer l'emplacement avec --workingDir ou --src.

inso run test "Smoke Suite" --env "CI"
inso run collection "User API" --env "Staging"
inso script seed-data --env env_staging

Le modèle basé sur le nom est propre si votre équipe s'engage sur le dossier .insomnia et le considère comme la source de vérité. Cela signifie que votre extraction CI a besoin de ce dossier, et que les noms doivent rester stables.

Apidog CLI exécute des scénarios de test qui résident dans le projet Apidog. Vous vous authentifiez avec un login ou un jeton d'accès, puis exécutez un scénario ou une collection contre un environnement choisi. La définition provient du projet, donc le même scénario que votre équipe a construit dans l'interface graphique est celui qui s'exécute en CI, pas de dossier à committer et à maintenir aligné.

apidog run -t <scenario-or-collection> -e <environment>

Aucun des deux modèles n'est mauvais. inso privilégie un dossier local committé sur Git. Apidog privilégie un projet de référence synchronisé. Choisissez celui qui correspond à la façon dont votre équipe partage déjà les définitions d'API.

Tests basés sur les données

Si vous devez exécuter le même scénario sur de nombreuses lignes d'entrée, cela est important.

Apidog CLI prend en charge les tests basés sur les données directement avec -d, en pointant vers un jeu de données CSV ou JSON. Chaque ligne devient une itération avec ses propres variables, de sorte qu'un scénario couvre des dizaines de cas.

apidog run -t "Checkout Flow" -e "Staging" -d ./datasets/orders.csv

Le modèle complet, y compris la façon dont les variables sont mappées aux colonnes, se trouve dans les tests basés sur les données avec Apidog CLI.

inso n'expose pas de flag de type "data-driven" dans ses commandes d'exécution. Vous pouvez paramétrer via des environnements, et vous pouvez piloter les itérations en scriptant autour d'inso dans votre tâche CI, mais l'itération ligne par ligne CSV/JSON n'est pas une fonctionnalité CLI de premier ordre comme elle l'est dans Apidog. Si l'itération sur un jeu de données est centrale pour votre suite, c'est une réelle différence à considérer.

Rapporteurs : ce que vous obtenez en retour

Les rapports sont la façon dont la CI vous indique ce qui s'est passé. Les deux outils échouent la construction en cas d'échec d'une assertion, mais ils diffèrent dans les formats de sortie.

Apidog CLI produit des rapports en formats CLI, HTML et JSON. Le format CLI est parfait pour un scan rapide des logs, le HTML vous donne un artefact partageable, et le JSON alimente les tableaux de bord ou les outils en aval. Vous pouvez également envoyer les résultats vers le cloud avec --upload-report pour un rapport hébergé et partageable. Le guide des rapports de test Apidog CLI décrit chaque format.

inso imprime les résultats des tests dans la console et signale le succès/échec via le code de sortie, ce sur quoi la plupart des systèmes CI se basent. Cela couvre le besoin essentiel. Si vous voulez un artefact HTML riche ou un rapport hébergé sans outils supplémentaires, Apidog vous en offre davantage ici.

Linting : la comparaison honnête

C'est là qu'inso a un véritable avantage, et ce serait un tort de prétendre le contraire.

inso "linte" les spécifications OpenAPI avec inso lint spec, et le linter sous le capot est Spectral, le linter OpenAPI bien connu de Stoplight. Cela signifie que vous pouvez faire respecter un guide de style, détecter les problèmes de contrat et bloquer les fusions en fonction de la qualité des spécifications, le tout depuis la même interface CLI qui exécute vos tests.

inso lint spec "Payments API"
inso export spec "Payments API" --output openapi.yaml

Pour les équipes qui pratiquent une conception "spec-first" et qui souhaitent que les règles de linting soient appliquées en CI, c'est une raison forte et réelle de choisir inso.

Maintenant, l'équivalent honnête pour Apidog. L'interface CLI Apidog ne dispose pas d'un linter OpenAPI autonome, ni de commandes pour les guides de style, la division, la fusion ou le regroupement. Apidog valide les spécifications lorsque vous les importez, ce qui détecte les problèmes structurels, mais il s'agit d'une validation à l'importation, et non d'une commande lint que vous exécutez contre un guide de style en CI. Ne vous attendez pas à ce que l'interface CLI d'Apidog remplace Spectral. Si le linting de contrat dans le pipeline est une exigence stricte et que vous n'avez pas d'étape Spectral séparée, inso le couvre et Apidog non.

Là où Apidog gagne sa place, c'est plutôt dans l'intégration et la gestion des ressources, ce qui est la prochaine section.

Ressource et branche en tant que code

Apidog CLI peut faire quelque chose qu'inso ne fait pas : gérer les ressources API en tant que code. Depuis le terminal, vous pouvez importer OpenAPI et travailler avec les points de terminaison, les schémas, les environnements, les branches et les requêtes de fusion. Cela vous permet de scripter les modifications de conception d'API et de les intégrer à la même automatisation qui exécute les tests.

inso reste dans son rôle de lanceur et de linter. Il peut exporter une spécification, mais ce n'est pas une interface CLI de gestion des ressources pour modifier des points de terminaison ou gérer des branches.

Pour les équipes qui souhaitent que leur définition d'API et leurs exécutions de tests soient gérées par la même interface CLI, la surface "ressource-as-code" d'Apidog est un avantage significatif. C'est en partie la raison pour laquelle le choix entre inso et Apidog se transforme souvent en une question de plateforme plutôt qu'une question de lanceur.

Intégration de la plateforme, open source et tarification

inso fait partie d'un écosystème open source. Insomnia est lui-même open source, ce qui séduit les équipes qui souhaitent inspecter ou auto-héberger leurs outils. Il est important de noter pour la planification : Insomnia 8 en 2023 a introduit un compte cloud/login obligatoire qui a suscité des réactions négatives, et il y a eu des incidents de migration et de perte de données à cette période. Si votre équipe évalue ces événements, nos articles sur la récupération et la migration des données perdues d'Insomnia et comment récupérer et exporter les données d'Insomnia couvrent les détails. Rien de tout cela ne change le fait qu'inso, l'interface CLI, est un lanceur solide et gratuit avec le linting Spectral intégré.

Apidog est une plateforme commerciale avec un niveau gratuit. Son argument est l'intégration : vous concevez, simulez, documentez, déboguez et testez en un seul endroit, et l'interface CLI est la surface d'automatisation pour cet espace de travail. Vous n'assemblez pas un outil de conception, un serveur de simulation et un exécuteur séparés. Pour une vue d'ensemble plus large du produit, consultez Apidog vs Insomnia et Insomnia vs Apidog. Si vous voulez d'abord essayer le lanceur contre une API en direct, les guides comment utiliser Insomnia pour tester une API et tester une API REST depuis la ligne de commande sont de bons points de départ.

Câblage CI, en bref

Les deux outils s'intègrent dans un pipeline de la même manière : installer, s'authentifier ou pointer vers vos données, exécuter, et laisser le code de sortie bloquer la construction.

# inso dans la CI
- run: brew install inso
- run: inso run test "Smoke Suite" --env "CI"

# Apidog CLI dans la CI
- run: apidog run -t "Smoke Suite" -e "CI" -r html,json

Si vous développez cela, le guide de pipeline CI/CD d'Apidog CLI et le guide détaillé GitHub Actions couvrent l'authentification, la mise en cache et le téléchargement de rapports. Les spécificités d'authentification pour le lanceur se trouvent dans le guide d'authentification Apidog CLI.

Le verdict

Il n'y a pas de gagnant unique. Le choix honnête dépend de la façon dont votre équipe travaille.

Choisissez inso si vous utilisez déjà Insomnia, si vous commitez un dossier .insomnia et si vous souhaitez que le linting de spécification Spectral soit appliqué en CI à partir du même outil qui exécute vos tests. L'écosystème open-source et le linter intégré sont de véritables atouts, et un lanceur gratuit, référencé par nom, convient parfaitement aux équipes qui privilégient Insomnia.

Choisissez l'Apidog CLI si vous voulez une plateforme unique pour la conception, la simulation, la documentation et les tests, avec des exécutions basées sur les données via -d, des rapporteurs plus riches (CLI, HTML, JSON, plus des rapports hébergés), et la gestion des ressources et des branches en tant que code. Vous renoncez à un linter CLI autonome, mais vous gagnez un flux de travail intégré où ce que vous concevez est ce que vous testez. La migration d'une configuration existante est simple ; voir migrer d'inso (CLI Insomnia) vers Apidog CLI.

Prêt à comparer en pratique ? Téléchargez Apidog et exécutez un scénario contre votre propre API.