Apidog CLI contre Newman : Automatiser les tests d'API en intégration continue (2026)

Vos tests d'API passent sur votre ordinateur portable. La question plus difficile est de savoir s'ils s'exécutent sur chaque pull request, chaque fusion et chaque build nocturne sans qu'un humain n'ait à cliquer. Ce travail appartient à un exécuteur en ligne de commande. Il prend les tests que vous avez déjà écrits, les exécute sans interface graphique dans votre pipeline, se termine avec un code d'état que votre CI peut lire, et écrit un rapport que votre tableau de bord peut analyser. Pas d'interface graphique, pas d'étape manuelle, pas d'excuse pour sauter l'exécution.

Pendant des années, la réponse par défaut à ce besoin a été Newman, l'exécuteur de collections en ligne de commande open-source de Postman. C'est un outil solide et bien compris, et de nombreuses équipes le choisissent encore en premier. Mais si vous créez vos tests dans Apidog au lieu de Postman, vous avez une deuxième option : l'Apidog CLI, qui exécute les mêmes scénarios de test que vous construisez visuellement dans l'application, sans interface graphique en CI. Cet article est une comparaison honnête, au niveau des commandes, des deux. Il couvre ce que Newman fait bien, où l'Apidog CLI s'insère, et ce que chacun d'eux apporte une fois intégré à un pipeline réel.

En bref

• Newman (`newman`, installé via `npm install -g newman`) exécute un fichier JSON de collection Postman exporté. Il est open source, gratuit et lit une collection ainsi qu'un fichier d'environnement depuis le disque ou une URL. Il prend en charge les environnements, les fichiers de données, les nombres d'itérations et les rapporteurs JUnit/JSON/HTML, et il se termine avec un code de sortie non nul lorsqu'un test échoue.
• Apidog CLI (`apidog-cli`, binaire `apidog`) exécute les scénarios de test que vous concevez dans l'application Apidog, récupérés par ID à l'aide d'un jeton d'accès. Vous n'exportez rien et ne maintenez pas de fichier JSON à la main ; le scénario visuel est le test, et la CLI l'exécute exactement comme l'application le ferait.
• Les deux s'intègrent à GitHub Actions, GitLab CI, Jenkins et tout ce qui utilise Node.js. Les deux font échouer le build en cas de test échoué. Le format JUnit XML est ce qui s'intègre aux tableaux de bord CI des deux côtés.
• Choisissez Newman lorsque vos tests existent déjà sous forme de collections Postman et que vous souhaitez un exécuteur gratuit, compatible avec les dépôts et sans nouveau compte.
• Choisissez Apidog CLI lorsque vous souhaitez une création visuelle, l'enchaînement des requêtes, la gestion des environnements et des exécutions basées sur des données qui restent synchronisées avec le même scénario que votre équipe débogue chaque jour.

Le vrai problème : des tests qui existent mais qui ne sont jamais exécutés

Un test que vous exécutez manuellement est un test qui se dégrade. Quelqu'un l'a construit, il a réussi une fois, puis il est resté intouché tandis que l'API évoluait en dessous. Plus de tests ne résolvent pas ce problème. Les tests qui s'exécutent automatiquement à chaque changement le font, car ils produisent un signal de réussite ou d'échec sur lequel votre pipeline peut agir.

Un exécuteur CLI comble cette lacune. Pour être utile en CI, il doit faire trois choses : s'exécuter sans interface graphique, se terminer avec un code non nul en cas d'échec pour que le build passe au rouge, et écrire un rapport lisible par machine afin que les relecteurs puissent voir ce qui a échoué. Newman et l'Apidog CLI atteignent tous deux ce niveau sans problème. Là où ils diffèrent, c'est en amont de la commande d'exécution, dans la façon dont le test a été écrit et où il réside. Si vous mettez en place la CI à partir de zéro, les modèles plus larges de l'automatisation des tests d'API en CI/CD s'accordent bien avec cette comparaison. Ici, nous nous concentrons sur les deux exécuteurs.

Ce que Newman fait bien

Newman a gagné sa place. C'est le compagnon open-source officiel de Postman, et pour les équipes dont les tests existent déjà sous forme de collections Postman, c'est le chemin le plus direct de « tests sur ma machine » à « tests en CI ». Il est utile d'énoncer clairement ses points forts avant toute comparaison.

Il est gratuit et open source. Vous l'installez via npm et l'exécutez partout où Node.js fonctionne, sans licence séparée pour l'exécuteur lui-même. Votre collection est un fichier JSON portable que vous pouvez commiter dans un dépôt, stocker comme artefact de build, ou récupérer depuis une URL. Cette portabilité est réelle, et cela signifie que Newman s'intègre à presque n'importe quel pipeline sans friction.

Il réutilise ce que vous avez déjà construit. Si votre équipe écrit des requêtes, des scripts de pré-requête et des assertions de test dans Postman, Newman exécute ces mêmes collections sans modification. Il n'y a pas de réécriture. Les scripts que vous avez écrits dans l'éditeur Postman s'exécutent de la même manière lors de l'exécution sans interface graphique, ce qui maintient la courbe d'apprentissage plate pour les utilisateurs de Postman.

Son installation se fait en une seule commande :

npm install -g newman

Le binaire est `newman`. Vous exécutez une collection exportée en le pointant vers le fichier JSON, généralement accompagné d'un fichier d'environnement :

newman run api-tests.postman_collection.json -e staging.postman_environment.json

C'est la boucle principale. Exportez la collection de Postman, commitez le JSON et exécutez-la. Newman lit les requêtes et les assertions du fichier et les exécute dans l'ordre. Pour le chemin de configuration complet, le guide d'Apidog sur comment installer Newman et exécuter des collections Postman couvre le flux d'exportation et d'exécution étape par étape.

Newman prend également en charge les éléments essentiels de CI auxquels vous vous attendez. Les exécutions basées sur des données proviennent d'un fichier CSV ou JSON :

newman run api-tests.postman_collection.json \
  -e staging.postman_environment.json \
  -d users.csv \
  -n 5

Ici, `-d` fournit le fichier de données et `-n` définit le nombre d'itérations, de sorte que la collection s'exécute une fois par ligne ou un nombre fixe de fois. Ce sont les mêmes primitives dont tout exécuteur sérieux a besoin, et Newman les possède depuis des années.

Là où Newman commence à vous coûter cher

Les atouts mentionnés ci-dessus sont réels, mais les compromis le sont tout autant, et ils apparaissent dans la maintenance quotidienne plutôt que dans une seule commande.

Le plus important est l'étape d'exportation. Une collection Postman en CI est un instantané. Vous créez et déboguez dans l'application Postman, puis exportez un fichier JSON pour l'exécuter sans interface graphique. Au moment où quelqu'un modifie une requête dans l'application et oublie de la réexporter, votre collection commitée s'éloigne de la source de vérité. L'exécution CI continue de passer contre une ancienne définition tandis que la vraie API a évolué. Rien dans l'outillage ne force les deux à se synchroniser ; c'est à celui qui se souvient d'exporter de le faire.

Le scripting est l'autre point. La logique de test Postman réside dans des extraits de code JavaScript attachés à chaque requête, et ces scripts sont le lieu où se produisent l'enchaînement, l'extraction de variables et les assertions. C'est flexible, mais cela signifie que votre suite de tests est un ensemble de petits scripts à écrire, déboguer et maintenir à la main. À mesure que les scénarios se développent, la surface de script que vous possédez augmente. Cela fait partie d'un modèle plus large que les équipes rencontrent à mesure que les collections évoluent, que nous abordons dans les restrictions du Postman Collection Runner et comment les contourner.

Rien de tout cela ne fait de Newman un mauvais outil. Cela en fait un exécuteur dont l'ergonomie est liée au modèle d'auteur de Postman : des scripts plus une étape d'exportation. Si ce modèle convient à votre équipe, Newman est parfait. Si la danse d'exportation et de synchronisation est ce qui continue de poser problème, c'est exactement là qu'un exécuteur différent peut aider.

Ce que l'Apidog CLI fait différemment

Apidog emprunte un chemin différent vers le même pipeline. Vous construisez des tests visuellement dans l'application Apidog. Vous enchaînez des requêtes en un scénario de test, ajoutez des assertions dans un éditeur sans code, extrayez une valeur d'une réponse vers la requête suivante, et répétez le tout sur un fichier de données. La CLI est l'exécuteur sans interface graphique de ces scénarios. Elle n'a pas de format de fichier séparé et rien à exporter. Elle récupère le scénario que vous nommez par ID depuis votre projet Apidog et l'exécute exactement comme l'application le ferait.

Cela élimine le problème de dérive. Le scénario dans le projet est le test. Il n'y a pas d'instantané exporté qui puisse se désynchroniser, car la CLI exécute le scénario en direct, et non une copie. Vous le créez une fois dans un constructeur visuel qui gère l'enchaînement des requêtes et les assertions pour vous, puis le même scénario s'exécute en CI. La boucle de création rapide et la boucle d'automatisation partagent une seule source de vérité.

L'installation se fait avec une seule commande npm :

npm install -g apidog-cli

Le binaire est `apidog`. Une exécution typique nomme un scénario par ID, choisit un environnement et s'authentifie avec un jeton d'accès :

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r html,junit

Vous ne saisissez pas ces ID à la main. Ouvrez le scénario de test dans Apidog, passez à son onglet CI/CD, générez un jeton d'accès, et Apidog construit la commande complète pour vous avec l'ID du scénario et l'ID de l'environnement déjà renseignés. Vous la copiez une fois, puis déplacez le jeton dans un secret CI et le référencez comme `$APIDOG_ACCESS_TOKEN`. Si vous n'êtes pas sûr des options prises en charge par votre version installée, exécutez `apidog run --help` et il affichera les options exactes disponibles.

Le modèle basé sur un jeton et la récupération par ID est la différence la plus claire avec Newman. Newman lit un fichier de collection depuis le disque ; l'Apidog CLI accède à un projet via le réseau, authentifié, et exécute le scénario qui y est stocké. Aucun n'est erroné. Ils conviennent à différentes configurations d'équipe, et le choix porte principalement sur le fait de vouloir que le test réside sous forme de fichier exporté ou de scénario en direct dans un espace de travail partagé.

Comparaison

Deux choses ressortent. Premièrement, les deux exécuteurs couvrent les mêmes éléments essentiels de CI : la sélection d'environnement, l'itération basée sur les données, les formats de rapport importants et une sortie non nulle en cas d'échec. Les noms des drapeaux sont même suffisamment proches pour que la mémoire musculaire se transfère (`-e`, `-d`, `-n`, `-r`). Deuxièmement, la vraie divergence ne concerne pas la capacité brute. Elle réside dans l'endroit où le test vit et comment vous l'avez écrit. Newman exécute une collection exportée rédigée avec des scripts. Apidog exécute un scénario visuel en direct par référence. Une version plus approfondie de cette comparaison, centrée sur les deux exécuteurs du monde Postman, se trouve dans Postman CLI vs Newman si vous souhaitez également cet angle.

Rapporteurs et codes de sortie : les éléments que la CI lit réellement

Un exécuteur gagne sa place dans un pipeline grâce à deux comportements : le rapport qu'il écrit et le code de sortie qu'il renvoie. Maîtrisez-les, et le reste est une question de câblage.

Newman sélectionne les rapporteurs avec le drapeau `-r` et une liste séparée par des virgules. JUnit et JSON sont inclus ; le rapporteur HTML est le complément le plus courant :

newman run api-tests.postman_collection.json \
  -e staging.postman_environment.json \
  -r cli,junit \
  --reporter-junit-export ./results/junit.xml

Le XML JUnit est ce que votre tableau de bord CI analyse pour créer une arborescence de réussite ou d'échec. Le drapeau `--bail` de Newman arrête l'exécution après la première défaillance, ce qui permet un retour rapide sur un test de fumée. Sans cela, l'exécution se termine et signale tous les échecs en une seule fois.

L'Apidog CLI utilise le même drapeau `-r` séparé par des virgules et écrit tout dans un seul répertoire de sortie :

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 \
  -r html,junit --out-dir ./apidog-reports

Son drapeau `--on-error` façonne le comportement en milieu de scénario : `end` s'arrête à la première défaillance et est la valeur par défaut, `continue` exécute chaque étape afin que vous puissiez collecter toutes les défaillances dans un seul rapport, et `ignore` passe outre une étape connue pour être instable. Dans tous les cas, l'exécution se termine avec un code non nul si quelque chose a échoué.

Le contrat du code de sortie est le même des deux côtés, et c'est la partie essentielle. Lorsqu'une assertion échoue, l'exécuteur se termine avec un code non nul. La CI lit ce code, marque l'étape comme échouée, fait échouer le job et bloque la fusion ou le déploiement. Vous ne configurez rien de plus. Le seul piège, identique pour les deux, est d'engloutir le code de sortie : enveloppez l'exécution dans un pipeline shell ou ajoutez `|| true` et la sortie non nulle est ignorée, de sorte que la passerelle cesse silencieusement de fonctionner. Ne faites pas cela. Pour le contexte plus large sur les formats de rapport, les tests d'API basés sur les données avec CSV ou JSON montrent comment le rapport est lié aux données d'itération.

Newman dans GitHub Actions

Étant donné que la collection est un fichier exporté dans le dépôt, le workflow est court. Extrayez le code, installez Newman, exécutez la collection, téléchargez le rapport même en cas d'échec.

name: Tests API

on:
  pull_request:
    branches: [main]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Configurer Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Installer Newman
        run: npm install -g newman

      - name: Exécuter les tests API
        run: |
          newman run ./tests/api-tests.postman_collection.json \
            -e ./tests/staging.postman_environment.json \
            -r cli,junit \
            --reporter-junit-export ./results/junit.xml

      - name: Télécharger le rapport
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: newman-report
          path: ./results

Aucun secret n'est nécessaire si les fichiers de collection et d'environnement sont commités dans le dépôt. La ligne `if: always()` maintient le téléchargement du rapport même lorsque les tests échouent, ce qui est précisément le moment où vous voulez le lire. Le coût que vous assumez est l'étape d'exportation qui a produit ces fichiers JSON en premier lieu, et le fait de devoir les actualiser lorsque l'API change.

Apidog CLI dans GitHub Actions

Le workflow Apidog a la même structure, avec un changement : le jeton d'accès provient des secrets du dépôt, et vous sélectionnez le scénario par ID au lieu de pointer vers un fichier.

name: Tests API

on:
  pull_request:
    branches: [main]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Configurer Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Installer Apidog CLI
        run: npm install -g apidog-cli

      - name: Exécuter le scénario de test API
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t 605067 \
            -e 1629989 \
            -r html,junit \
            --out-dir ./apidog-reports
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

      - name: Télécharger le rapport
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: apidog-report
          path: ./apidog-reports

Remarquez la symétrie. Même extraction, même configuration Node, même forme d'installation-puis-exécution, même téléchargement systématique. Les seules vraies différences sont le jeton câblé en tant que secret et le scénario sélectionné par ID plutôt que par chemin de fichier. Étant donné que le scénario est récupéré en direct, il n'y a pas de fichier JSON à maintenir à jour. Pour le même modèle dans d'autres systèmes, comment automatiser les tests d'API dans GitHub Actions transfère la structure à GitLab CI et Jenkins.

Comment choisir

La décision dépend rarement de l'exécuteur qui est objectivement meilleur. Elle dépend de l'endroit où vos tests résident déjà et de la manière dont votre équipe souhaite les maintenir.

Choisissez Newman lorsque vos tests sont déjà des collections Postman. Si votre suite réside dans Postman, que votre équipe écrit des scripts de test dans l'éditeur, et que vous voulez un exécuteur gratuit et open source qui s'intègre à n'importe quel pipeline sans nouveau compte, Newman est le choix direct. C'est le choix naturel pour les utilisateurs de Postman qui sont à l'aise avec l'exportation d'une collection et le commit du JSON, et qui ne craignent pas de gérer les scripts de test manuellement. Vous pouvez en savoir plus sur les différences au sein de l'écosystème Postman dans quelle est la différence entre Newman et Postman.

Choisissez l'Apidog CLI lorsque la rapidité de création et une source unique de vérité importent plus que de rester dans Postman. Si vous préférez construire un scénario de test visuellement, enchaîner les requêtes, extraire des variables et exécuter ce même scénario à travers différents environnements sans écrire ni réexporter de code de test, Apidog supprime cette friction. Concevez, déboguez, simulez et testez en direct dans un seul espace de travail, et la CLI exécute le scénario exact que vous avez construit. Pour les équipes venant de Postman, la migration est une option qu'Apidog propose comme alternative à Postman pour les tests d'API, et l'importation se fait en un clic.

Il existe également une réponse qui utilise les deux outils. Certaines équipes maintiennent une étape Newman existante exécutant leurs collections héritées tout en déplaçant de nouveaux scénarios enchaînés plus complexes vers Apidog. Les deux CLI coexistent parfaitement dans un même pipeline ; ce sont des étapes distinctes avec des codes de sortie séparés, et vous pouvez retirer l'étape Newman selon votre propre calendrier.

Pour configurer votre premier scénario automatisé et l'exécuter depuis le terminal le même après-midi, téléchargez Apidog, construisez un scénario de test et copiez la commande générée depuis son onglet CI/CD.