Vos tests API passent en local. Le vrai enjeu est de les exécuter automatiquement à chaque pull request, fusion et build nocturne, sans clic manuel. Pour cela, vous avez besoin d’un exécuteur CLI : il lance vos tests en mode headless, retourne un code de sortie exploitable par la CI et génère un rapport lisible par votre pipeline.

Essayez Apidog aujourd'hui

Deux outils reviennent souvent pour ce cas d’usage : le CLI Bruno et le CLI Apidog. Les deux exécutent des tests API depuis GitHub Actions, GitLab CI, Jenkins ou tout environnement Node.js. Les deux font échouer la build lorsqu’un test échoue. La différence principale se situe avant l’exécution : où vivent les tests, comment ils sont créés et comment la CI y accède.

Cet article compare les deux outils au niveau commande, avec des exemples directement intégrables dans un pipeline.

En bref

• CLI Bruno (@usebruno/cli, binaire bru) exécute des fichiers .bru présents dans votre dépôt Git. Il est open source, fonctionne hors ligne et ne nécessite ni compte ni jeton.
• CLI Apidog (apidog-cli, binaire apidog) exécute des scénarios de test créés visuellement dans Apidog, récupérés par ID avec un jeton d’accès.
• Les deux génèrent des rapports JUnit, JSON et HTML.
• Les deux retournent un code non nul en cas d’échec, ce qui permet à la CI de bloquer une fusion ou un déploiement.
• Choisissez Bruno si vous voulez des tests versionnés comme du code, dans le dépôt.
• Choisissez Apidog si vous voulez créer, chaîner et exécuter des scénarios visuels sans maintenir manuellement des fichiers de test.

Le problème : des tests qui existent mais ne tournent pas

Un test API lancé manuellement finit souvent par devenir obsolète. Il a été écrit, validé une fois, puis oublié pendant que l’API évoluait.

La solution n’est pas seulement d’ajouter plus de tests. Il faut les exécuter automatiquement à chaque changement avec un signal clair :

• succès ou échec ;
• rapport exploitable ;
• code de sortie lisible par la CI.

Un exécuteur CLI doit donc remplir trois conditions :

1. fonctionner sans interface graphique ;
2. retourner un code non nul en cas d’échec ;
3. produire un rapport lisible par machine, idéalement JUnit XML.

Bruno et Apidog remplissent ces conditions. Leur différence se situe dans la source du test :

• Bruno lit des fichiers .bru depuis le disque ;
• Apidog récupère un scénario depuis un projet Apidog.

Si vous mettez en place une stratégie CI/CD complète, lisez aussi ce guide sur l’automatisation des tests API en CI/CD.

Ce que le CLI Bruno fait bien

Bruno adopte une approche Git-native. Chaque requête, environnement et assertion est stocké dans un fichier .bru en texte brut.

Cela donne un workflow simple :

• les tests vivent dans le dépôt ;
• les modifications de tests passent dans les mêmes pull requests que le code ;
• les diffs sont lisibles ;
• les conflits se résolvent dans un éditeur ;
• aucun compte ni jeton n’est nécessaire pour exécuter le CLI.

C’est utile si votre équipe traite les tests comme du code et veut éviter toute dépendance à un service distant pendant l’exécution.

Installation :

npm install -g @usebruno/cli

Le binaire est bru.

Depuis le dossier contenant la collection :

bru run --env staging

Pour exécuter aussi les requêtes dans les sous-dossiers :

bru run -r --env staging

Dans ce modèle, les fichiers du dépôt sont la source de vérité. Le CLI ne récupère rien à distance.

Pour aller plus loin sur le positionnement de Bruno, consultez ces articles sur ce qui rend Bruno différent en tant que client API Git-native et sur ses limites pour les grandes équipes.

Ce que le CLI Apidog fait bien

Apidog fonctionne différemment. Vous créez vos tests dans l’application Apidog sous forme de scénarios :

• enchaînement de requêtes ;
• assertions ;
• extraction de valeurs depuis les réponses ;
• réutilisation de variables ;
• exécution basée sur des données CSV ou JSON.

Le CLI exécute ensuite ces scénarios en mode headless.

Installation :

npm install -g apidog-cli

Le binaire est apidog.

Exemple d’exécution :

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

Les paramètres principaux sont :

• --access-token : jeton d’accès ;
• -t : ID du scénario ;
• -e : ID de l’environnement ;
• -n : nombre d’itérations ;
• -r : formats de rapport.

En pratique, vous n’avez pas besoin de deviner ces ID. Dans Apidog :

1. ouvrez le scénario de test ;
2. allez dans l’onglet CI/CD ;
3. générez un jeton d’accès ;
4. copiez la commande générée ;
5. stockez le jeton dans un secret CI, par exemple APIDOG_ACCESS_TOKEN.

La référence complète des options est disponible dans le guide complet du CLI Apidog.

Comparaison côte à côte

Les deux couvrent les besoins CI essentiels : sélection d’environnement, données de test, rapports et code de sortie non nul. Le choix dépend surtout de la source de vérité :

• dépôt Git pour Bruno ;
• scénario visuel Apidog pour Apidog.

Rapports et codes de sortie

En CI, deux éléments comptent vraiment :

1. le rapport généré ;
2. le code de sortie.

Générer des rapports avec Bruno

bru run -r --env staging \
  --reporter-junit ./results/junit.xml \
  --reporter-html ./results/report.html \
  --reporter-json ./results/report.json

Utilisez :

• --reporter-junit pour produire un XML JUnit lisible par la CI ;
• --reporter-html pour générer un artefact consultable ;
• --reporter-json pour un post-traitement personnalisé.

Pour arrêter l’exécution au premier échec :

bru run -r --env staging --bail

Générer des rapports avec Apidog

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

Le flag -r accepte plusieurs formats séparés par des virgules.

Pour contrôler le comportement en cas d’erreur :

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

Options courantes :

• --on-error end : arrête à la première erreur ;
• --on-error continue : continue pour collecter toutes les erreurs ;
• --on-error ignore : ignore certaines erreurs connues.

Dans les deux cas, si une assertion échoue, le CLI retourne un code non nul. La CI marque alors l’étape comme échouée.

Évitez ceci :

bru run -r --env staging || true

ou :

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 || true

|| true masque l’échec et empêche la CI de bloquer la fusion.

Utiliser le CLI Bruno dans GitHub Actions

Comme les fichiers .bru sont déjà dans le dépôt, le workflow est direct :

name: Tests API

on:
  pull_request:
    branches: [main]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - name: Récupération du code
        uses: actions/checkout@v4

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

      - name: Installation du CLI Bruno
        run: npm install -g @usebruno/cli

      - name: Exécution des tests API
        working-directory: ./api-tests
        run: bru run -r --env staging --reporter-junit ./results/junit.xml

      - name: Téléchargement du rapport
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: rapport-bruno
          path: ./api-tests/results

Points importants :

• working-directory doit pointer vers le dossier de la collection Bruno ;
• if: always() permet de récupérer le rapport même si les tests échouent ;
• aucun secret n’est nécessaire pour exécuter Bruno.

Utiliser le CLI Apidog dans GitHub Actions

Avec Apidog, le workflow est similaire, mais vous devez fournir un jeton d’accès via les secrets GitHub.

name: Tests API

on:
  pull_request:
    branches: [main]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - name: Récupération du code
        uses: actions/checkout@v4

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

      - name: Installation du CLI Apidog
        run: npm install -g apidog-cli

      - name: Exécution du 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échargement du rapport
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: rapport-apidog
          path: ./apidog-reports

À configurer côté GitHub :

1. ouvrez les paramètres du dépôt ;
2. allez dans Secrets and variables ;
3. ajoutez APIDOG_ACCESS_TOKEN ;
4. collez le jeton généré depuis l’onglet CI/CD d’Apidog.

Le guide complet du CLI Apidog montre aussi des variantes pour GitLab CI et Jenkins.

Exécuter sans installation globale

Sur des runners CI éphémères, vous pouvez éviter l’installation globale.

Avec Bruno :

npx @usebruno/cli run -r --env staging

Avec Apidog :

npx apidog-cli run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989

Vérifiez les options disponibles dans votre version :

bru run --help

apidog run --help

Comment choisir

Le bon choix dépend de votre workflow de test.

Choisissez Bruno si le dépôt est la source de vérité

Bruno convient si vous voulez :

• stocker les tests dans Git ;
• relire les changements de tests dans les pull requests ;
• exécuter hors ligne ;
• éviter comptes et jetons ;
• manipuler des fichiers texte avec vos outils habituels.

C’est un bon choix pour les équipes qui veulent traiter les tests API comme du code versionné.

Choisissez Apidog si vous voulez accélérer la création de scénarios

Apidog convient si vous voulez :

• construire les scénarios visuellement ;
• chaîner plusieurs requêtes ;
• extraire des variables entre étapes ;
• exécuter les mêmes scénarios sur plusieurs environnements ;
• éviter la maintenance manuelle de fichiers de test.

Le scénario créé dans Apidog devient la source de vérité, et le CLI l’exécute tel quel en CI.

Pour les équipes venant de Postman, Apidog peut aussi s’inscrire dans une migration plus large. Voir cette comparaison des alternatives à Postman pour les tests d’API.

Vous pouvez aussi utiliser les deux

Les deux CLI peuvent coexister dans le même pipeline :

• Bruno pour des vérifications bas niveau versionnées dans Git ;
• Apidog pour des scénarios de bout en bout plus complexes.

Chaque outil devient une étape distincte avec son propre code de sortie.

Si vous comparez les plateformes au-delà du CLI, cette comparaison Apidog vs Bruno couvre aussi la conception, le mocking et la collaboration.

Foire aux questions

Le CLI Bruno est-il gratuit ?

Oui. Le CLI Bruno est open source et distribué comme package npm @usebruno/cli. Il s’exécute localement ou en CI sans compte ni jeton. Bruno Ultimate est un niveau payant séparé avec des fonctions d’équipe et de gouvernance comme le SSO, le SCIM, les intégrations de gestionnaires de secrets et l’audit.

Le CLI Apidog est-il gratuit ?

Le CLI est un package npm gratuit : apidog-cli. Il exécute les scénarios de test de votre projet Apidog. Ce que vous pouvez exécuter dépend donc de votre plan Apidog, mais le CLI n’est pas un produit payant séparé.

Dois-je écrire les tests sous forme de code ?

Avec Bruno, les tests sont des fichiers .bru que vous pouvez éditer directement ou générer via l’application Bruno.

Avec Apidog, vous créez les scénarios visuellement dans l’application, puis le CLI les exécute par ID. Vous n’avez pas à maintenir manuellement le code de test.

Les deux CLI font-ils échouer la build ?

Oui. Les deux retournent un code non nul lorsqu’une assertion échoue. La CI utilise ce code pour marquer l’étape comme échouée et bloquer la fusion ou le déploiement.

Bruno peut s’arrêter au premier échec avec :

bru run --bail

Apidog utilise :

apidog run --on-error end

--on-error end est le comportement par défaut.

Quel format de rapport utiliser en CI ?

Utilisez JUnit XML pour l’intégration CI, car c’est le format le plus couramment analysé par les tableaux de bord.

Avec Bruno :

bru run -r --reporter-junit ./results/junit.xml

Avec Apidog :

apidog run -r junit --out-dir ./apidog-reports

Ajoutez HTML si vous voulez un rapport consultable comme artefact.

Le CLI Bruno nécessite-t-il Internet ?

Non. Bruno exécute les fichiers .bru depuis le dépôt local. Il ne nécessite pas de connexion ni de récupération distante, ce qui convient aux environnements isolés.

Le CLI Apidog, lui, s’authentifie avec un jeton d’accès et récupère le scénario depuis votre projet Apidog. Il nécessite donc un accès réseau au service Apidog pendant l’exécution.

Puis-je lancer les CLI avec npx ?

Oui.

Bruno :

npx @usebruno/cli run -r --env staging

Apidog :

bash
npx apidog-cli run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989