Comment automatiser les tests d'API dans Travis CI avec Apidog CLI

Votre API fonctionne sur votre machine. Les tests unitaires sont au vert. Vous fusionnez, déployez, et une heure plus tard, un coéquipier vous contacte : le point de terminaison /checkout renvoie une erreur 500 pour toute personne ayant un panier vide. Le bug n'a jamais été dans le code que vous avez modifié ; il se trouvait dans un contrat deux services plus loin que personne n'avait re-testé. C'est le fossé que comblent les tests d'API au niveau de l'intégration, et c'est exactement le type de vérification que vous voulez exécuter automatiquement à chaque commit au lieu de le faire de tête.

Travis CI est l'un des plus anciens services d'intégration continue hébergés, et il fait toujours une chose très bien : il surveille votre dépôt Git, crée un environnement propre pour chaque push et pull request, et exécute toutes les commandes que vous mettez dans un fichier .travis.yml. La plupart des équipes l'utilisent pour les boucles de compilation et de tests unitaires. Beaucoup moins l'utilisent pour exécuter de véritables tests HTTP contre une API en cours d'exécution, même si c'est là que se cachent les bugs coûteux. La raison est la friction. Connecter un exécuteur de tests d'API à une machine CI, transmettre les secrets en toute sécurité et obtenir un signal de réussite/échec est suffisamment délicat pour que les gens l'ignorent.

Ce guide explique comment combler cette lacune avec l'exécuteur en ligne de commande Apidog. Vous concevez et déboguez vos tests d'API dans l'application de bureau Apidog, où vous pouvez visualiser les requêtes et les assertions, puis exécuter ces mêmes tests sans interface graphique (headless) à l'intérieur de Travis CI avec une seule commande. Pas de réécriture de la logique de test sous forme de code, pas de maintenance d'un harnais de test séparé. L'article couvre le chemin complet : un fichier .travis.yml minimal, l'installation de l'exécuteur, la transmission sécurisée de votre jeton d'accès, le choix de ce qu'il faut exécuter, la génération de rapports et la façon de faire échouer la build de manière visible lorsqu'un point de terminaison tombe en panne. Téléchargez Apidog si vous souhaitez suivre.

Pourquoi exécuter des tests API dans la CI ?

Les tests unitaires confirment qu'une fonction renvoie la bonne valeur. Les tests API confirment que l'ensemble du cycle requête-réponse se comporte correctement : la route existe, l'authentification est appliquée, le code de statut est correct, le schéma JSON correspond, et les valeurs à l'intérieur du corps sont valides. Ce sont des modes de défaillance différents, et le second type est celui que vos utilisateurs rencontrent réellement.

Les exécuter localement, c'est bien jusqu'à ce que ça ne le soit plus. Les exécutions locales dépendent de votre capacité à vous souvenir de les lancer, de votre machine correspondant à la configuration de production, et de votre absence de pause-café lorsqu'une régression se faufile. L'intégration continue supprime ces trois excuses. Chaque push déclenche la même suite dans le même environnement, et le résultat est attaché au commit et à la pull request pour que tout le monde puisse le voir.

Il y a un avantage plus profond pour les équipes API en particulier. Lorsque vos tests coexistent avec la conception de votre API, un changement cassant apparaît comme une assertion échouée dès qu'il est poussé, et non comme un ticket de support. Si vous souhaitez le contexte conceptuel de sa place dans un pipeline de livraison, l'explication qu'est-ce que la CI/CD est une bonne lecture complémentaire ; cet article reste concentré sur la construction pratique avec Travis CI.

Ce dont vous avez besoin avant de commencer

Trois choses, et vous en avez probablement déjà deux.

• Un dépôt Git connecté à Travis CI. Le niveau gratuit sur travis-ci.com fonctionne pour les dépôts publics et privés dans les limites d'utilisation.

• Un projet Apidog avec au moins un scénario de test que vous avez déjà construit et exécuté avec succès dans l'application de bureau. Un scénario de test dans Apidog est un ensemble ordonné de requêtes API avec des assertions ; considérez-le comme un flux de bout en bout, comme « se connecter, créer une commande, récupérer la commande, la supprimer ».
• Node.js. L'interface de ligne de commande (CLI) Apidog fonctionne sur Node et nécessite la version 16 ou ultérieure. Travis fournit Node de manière prête à l'emploi dans l'environnement de langage node_js, il s'agit donc principalement d'une déclaration sur une seule ligne.

Si vous n'avez pas encore construit de scénario de test, faites-le d'abord dans l'application. Le but de ce workflow est de déboguer visuellement une fois, puis d'automatiser pour toujours. Tenter d'écrire des tests à l'aveugle dans un journal CI est la voie lente. Pour les bases de l'écriture de bonnes vérifications, Assertions API : un guide pratique couvre comment valider les codes de statut, les corps de réponse et le schéma JSON avant de pousser quoi que ce soit.

Étape 1 : Obtenez votre jeton d'accès et l'ID du scénario

L'interface de ligne de commande Apidog exécute vos tests stockés dans le cloud sans interface graphique (headless), elle a donc besoin de deux éléments d'identité :

1. Un jeton d'accès qui prouve que l'exécuteur est autorisé à lire votre projet. Générez-le depuis les paramètres de votre compte Apidog sous les jetons d'accès. Traitez-le comme un mot de passe ; il accorde l'accès API à vos données de projet.
2. Un ID de scénario de test. Ouvrez le scénario dans l'application de bureau et copiez son ID, ou utilisez l'option « Exécuter en CI/CD », qui génère une commande prête à l'emploi avec l'ID déjà rempli.

Le moyen le plus simple d'obtenir une première commande correcte est de laisser Apidog l'écrire pour vous. À l'intérieur d'un scénario de test, l'option d'exécution CI/CD produit quelque chose comme ceci :

apidog run --access-token <your-access-token> -t 5564321 -e 4417023 -r cli

C'est l'essentiel : s'authentifier, pointer vers un scénario (-t), pointer vers un environnement (-e), et choisir un rapporteur (-r). Copiez cela, assurez-vous que cela fonctionne d'abord sur votre propre ordinateur portable, et seulement ensuite déplacez-le dans Travis. La vérification locale vous évitera une douzaine de builds échouées à déboguer une faute de frappe dans un jeton.

Étape 2 : Stockez le jeton en tant que variable Travis chiffrée

Ne collez jamais votre jeton d'accès dans .travis.yml. Ce fichier est commité dans Git, et un jeton divulgué donne à quiconque un accès en lecture à votre projet API. Travis propose deux options sécurisées.

La méthode propre consiste à utiliser des variables d'environnement de dépôt définies dans l'interface utilisateur web de Travis. Allez dans les paramètres de votre dépôt sur Travis, trouvez les variables d'environnement, et ajoutez :

• APIDOG_ACCESS_TOKEN avec la valeur de votre jeton
• APIDOG_ENV_ID avec l'ID de l'environnement que vous souhaitez tester

Laissez l'option « afficher la valeur dans le journal de build » désactivée afin que le jeton ne s'affiche jamais. Travis les injecte dans chaque build en tant que véritables variables d'environnement, et votre configuration y fait référence par leur nom. Cela permet de garder les secrets entièrement hors du dépôt, ce qui est le comportement souhaité ; si un contributeur forke le dépôt, votre jeton ne l'accompagne pas.

Si vous préférez tout avoir dans le fichier, Travis prend également en charge les variables chiffrées via son CLI :

travis encrypt APIDOG_ACCESS_TOKEN="your-token-here" --add env.global

Cela écrit un blob chiffré dans .travis.yml que seule la build de votre dépôt peut déchiffrer. Les deux approches fonctionnent. La voie de l'interface utilisateur est plus simple pour la plupart des équipes et plus facile à renouveler lorsqu'un jeton expire.

Étape 3 : Écrire le .travis.yml

Voici une configuration complète et minimale qui installe l'interface de ligne de commande (CLI) Apidog et exécute un scénario à chaque push et pull request :

language: node_js
node_js:
  - "18"

cache:
  npm: true

install:
  - npm install -g apidog-cli

script:
  - apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_ENV_ID -r cli

Trois blocs font le travail. language: node_js avec une version vous donne un environnement d'exécution Node suffisamment récent pour la CLI. L'étape install installe apidog-cli globalement afin que la commande apidog soit dans le PATH. L'étape script exécute vos tests. Le rapporteur -r cli imprime un résumé lisible succès/échec directement dans le journal Travis, ce que vous regarderez lorsque quelque chose ne fonctionnera pas.

Remarquez que l'ID du scénario est codé en dur mais que les secrets proviennent de variables d'environnement. C'est la bonne séparation : l'ID n'est pas sensible, le jeton l'est. Commitez ce fichier, poussez, et Travis exécutera automatiquement vos tests API. La première build verte est le moment où votre API obtient un filet de sécurité.

Si vous maintenez plusieurs services et souhaitez un modèle mental partagé entre les exécuteurs, le guide automatiser les tests d'API en CI/CD montre le même modèle appliqué à d'autres plateformes, et la version GitHub Actions est presque identique dans l'esprit si jamais vous migrez.

Étape 4 : Faire échouer la build lorsqu'un test échoue

C'est la partie que les équipes oublient, et cela sabote discrètement tout l'exercice. Un travail de CI n'est utile que si un test échoué fait échouer la build. Si l'exécuteur se termine avec un code zéro quoi qu'il arrive, vous avez construit une imprimante de journaux très coûteuse.

Bonne nouvelle : la CLI Apidog fait déjà ce qu'il faut. Lorsqu'une assertion échoue, le processus apidog run se termine avec un code de statut non nul, et Travis traite toute sortie non nulle dans la phase script comme un échec de build. Ainsi, la configuration minimale ci-dessus échoue déjà correctement dès le départ. Vous n'avez pas besoin de colle supplémentaire.

Ce que vous pouvez ajuster, c'est le comportement de l'exécution en plein milieu du scénario lorsqu'une seule requête échoue. L'indicateur --on-error contrôle cela :

• --on-error end arrête le scénario à la première défaillance. Retour plus rapide, moins de sortie.
• --on-error continue exécute les étapes restantes afin que vous voyiez chaque échec en un seul passage.
• --on-error ignore continue et ne permet pas aux erreurs d'arrêter l'exécution.

Pour la CI, continue est généralement le meilleur compromis : vous voulez avoir une vue complète de ce qui a échoué sans que la tâche ne s'arrête après la première assertion rouge, tout en terminant avec une sortie non nulle pour que la build échoue. Une ligne de script raisonnable ressemble à ceci :

script:
  - apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_ENV_ID -r cli --on-error continue

Évitez la tentation d'ajouter || true à la commande pour « faire passer la build ». Cela ignore le code de sortie et réintroduit précisément l'angle mort que vous cherchiez à éliminer.

Étape 5 : Générer et conserver un rapport HTML

Le rapporteur cli est suffisant pour un aperçu rapide, mais lorsqu'une build échoue, vous souhaitez souvent un artefact plus riche : quelle requête, quelle assertion, quel était le corps de réponse réel. La CLI génère un rapport HTML avec le rapporteur html, et vous pouvez empiler les rapporteurs en une seule exécution.

script:
  - apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_ENV_ID -r cli,html --out-dir ./apidog-reports

-r cli,html imprime dans le journal et écrit un fichier HTML autonome. --out-dir définit l'emplacement du rapport, par défaut ./apidog-reports. Pour que ce rapport survive après la fin de la build, déployez-le quelque part où Travis peut le publier, comme un bucket S3 ou GitHub Pages, dans un bloc deploy. Un modèle courant :

deploy:
  provider: pages
  skip_cleanup: true
  github_token: $GITHUB_TOKEN
  local_dir: apidog-reports
  on:
    branch: main

Si vous préférez ne pas gérer du tout le stockage des artefacts, la CLI peut pousser le rapport vers le cloud Apidog avec --upload-report, où votre équipe peut l'ouvrir via un lien sans hébergement supplémentaire. C'est l'option la moins exigeante en maintenance pour les équipes distribuées.

Étape 6 : Ajouter des environnements, des données et des exécutions matricielles

Un seul scénario contre un seul environnement est un bon début. Les pipelines réels évoluent dans trois directions, et les drapeaux de la CLI correspondent précisément à chacune.

Plusieurs environnements. L'indicateur -e sélectionne les URL de base et les variables de l'environnement à utiliser. Exécutez le même scénario contre l'environnement de staging à chaque push et contre la production sur une build cron nocturne en échangeant l'ID de l'environnement. Les tâches cron Travis sont configurées par dépôt dans l'interface utilisateur des paramètres.

Exécutions basées sur les données. L'indicateur -d (forme longue --iteration-data) alimente votre scénario avec un fichier CSV ou JSON afin qu'il s'exécute une fois par ligne. C'est ainsi que vous couvrez les cas limites : entrée valide, champs manquants, charges utiles surdimensionnées, caractères spéciaux, le tout à partir d'une seule définition de scénario. Associez-le à -n (--iteration-count) lorsque vous souhaitez un nombre fixe de répétitions au lieu d'itérations pilotées par fichier.

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_ENV_ID -d ./test-data.csv -r cli

Scénarios parallèles. Les matrices de build Travis vous permettent d'exécuter plusieurs scénarios simultanément sur des jobs parallèles. Définissez une matrice de variables d'environnement où chaque entrée porte un ID de scénario différent, et chaque job de matrice en exécute un. La build ne passe au vert que lorsque tous réussissent.

env:
  - SCENARIO_ID=5564321   # checkout flow
  - SCENARIO_ID=5564322   # auth flow
  - SCENARIO_ID=5564323   # search flow

script:
  - apidog run --access-token $APIDOG_ACCESS_TOKEN -t $SCENARIO_ID -e $APIDOG_ENV_ID -r cli

À mesure que les suites s'agrandissent, l'organisation des scénarios en suites de tests pour les tests API automatisés permet de maintenir la matrice gérable au lieu de devenir un mur d'IDs.

Pourquoi c'est mieux que de coder les tests à la main dans votre script CI

Vous pourriez écrire des tests API directement dans un script Travis avec curl et jq, ou sous forme d'exécution Newman d'une collection exportée. Les deux fonctionnent, et les deux vieillissent mal.

L'approche curl-plus-shell transforme chaque assertion en une comparaison de chaînes fragile. Vérifier un champ JSON imbriqué devient une incantation jq ; vérifier un schéma est fondamentalement impossible ; et dès que votre API ajoute un champ, la moitié de vos greps doivent être réécrits. Vous finissez par maintenir une deuxième copie, pire, de votre connaissance API en Bash.

L'approche par exécuteur de collection est meilleure mais lie votre CI à un rituel d'exportation et de synchronisation : modifier les tests dans un outil, exporter, commiter le JSON, espérer qu'il n'a pas dévié de la réalité. La déviation est réelle, et c'est la source des plaintes « les tests passent mais l'API est cassée ». Nous avons écrit sur ce mode de défaillance exact dans pourquoi vos collections Postman ne sont pas une source de vérité, et si vous exécutez des collections en CI aujourd'hui, comment exécuter des collections Postman en CI sans Newman couvre le chemin de migration.

Le modèle Apidog supprime la boucle. Vos tests, la conception de votre API, vos environnements et vos serveurs de maquette vivent au même endroit. L'interface de ligne de commande exécute la version en direct et actuelle de ces tests ; il n'y a rien à exporter et rien à dériver. Vous déboguez une assertion instable visuellement dans l'application, enregistrez, et la prochaine exécution CI prend en compte le changement. Cette source unique de vérité est la raison principale d'utiliser un exécuteur conçu à cet effet plutôt qu'un tas de scripts shell. Si vous l'évaluez par rapport à votre configuration actuelle, le tour d'horizon des meilleures alternatives à Postman pour les tests API met les options côte à côte.

Une note spécifique sur Travis CI

Travis a été la CI open source par défaut pendant des années, et de nombreux dépôts plus anciens l'utilisent toujours. Si vous débutez en 2026, il est bon de savoir que le domaine a évolué ; GitHub Actions, GitLab CI et CircleCI gèrent désormais la plupart des nouveaux projets, et notre comparaison des meilleurs outils CI/CD détaille où chacun s'inscrit. La bonne nouvelle est que la CLI Apidog est agnostique à la plateforme par conception. La commande apidog run, qui fonctionne dans votre .travis.yml, fonctionne exactement de la même manière dans une étape GitHub Actions, un fichier .gitlab-ci.yml de GitLab, ou une étape Jenkins. Si jamais vous quittez Travis, vos tests API vous suivent inchangés ; seules les clés YAML environnantes diffèrent. Cette portabilité est un avantage discret mais réel de maintenir la logique de test hors de la syntaxe spécifique à la CI.

Questions fréquemment posées

Dois-je installer l'application de bureau Apidog sur la machine CI ? Non. L'application de bureau sert à concevoir et déboguer les tests. Travis n'a besoin que du package npm apidog-cli et d'un environnement d'exécution Node 16+, que l'environnement de langage node_js fournit déjà. La CLI récupère et exécute vos scénarios stockés dans le cloud sans interface graphique (headless).

Où puis-je trouver mon jeton d'accès et l'ID du scénario ? Générez le jeton d'accès dans les paramètres de votre compte Apidog sous les jetons d'accès. L'ID du scénario est visible dans l'application de bureau sur chaque scénario de test ; l'option intégrée « Exécuter en CI/CD » génère également une commande complète avec l'ID pré-rempli, ce qui est le moyen le plus rapide d'obtenir une base de travail.

Comment puis-je empêcher que le jeton soit visible dans mon dépôt ? Définissez-le comme une variable d'environnement de dépôt dans l'interface utilisateur web de Travis avec l'affichage du journal de build désactivé, puis référencez-le comme $APIDOG_ACCESS_TOKEN dans votre configuration. Alternativement, utilisez travis encrypt pour stocker une valeur chiffrée dans .travis.yml. Ne commitez jamais le jeton brut.

La build échouera-t-elle réellement si un test échoue ? Oui. La commande apidog run se termine avec un code non nul lorsqu'une assertion échoue, et Travis traite toute sortie non nulle dans la phase script comme un échec de build. N'omettez simplement pas de supprimer le code de sortie avec || true. Utilisez --on-error continue si vous voulez que chaque échec soit signalé en une seule exécution tout en faisant échouer la build.

Puis-je exécuter des tests sur plusieurs environnements ou avec plusieurs jeux de données ? Oui. Utilisez -e pour changer d'environnements (staging sur push, production sur un cron nocturne), -d pour alimenter un fichier de données CSV ou JSON pour des itérations basées sur les données, et une matrice de build Travis pour exécuter plusieurs scénarios dans des jobs parallèles.

Puis-je l'utiliser si je ne suis pas sur Travis CI ? Oui. La commande CLI est identique sur toutes les plateformes. Remplacez le YAML environnant pour GitHub Actions, GitLab CI ou Jenkins et la ligne apidog run reste la même.

En résumé

Intégrer des tests API dans Travis CI se résume à quatre étapes : stocker votre jeton d'accès en tant que variable chiffrée, installer apidog-cli à l'étape d'installation, exécuter votre scénario avec apidog run à l'étape de script, et laisser le code de sortie non nul faire échouer la build. À partir de là, vous ajoutez des rapports HTML, plusieurs environnements, des itérations basées sur les données et une matrice parallèle à mesure que votre suite grandit.

La raison de le faire avec un exécuteur dédié plutôt qu'un mur d'appels curl est la source unique de vérité. Vous concevez et déboguez visuellement, puis exécutez la version en direct de ces tests exacts à chaque commit, sans étape d'exportation pour se désynchroniser. Votre régression sur /checkout est détectée sur la pull request, et non en production.

Construisez votre premier scénario de test, puis téléchargez Apidog et intégrez-le à votre prochain push. Une fois que la première build passe au vert, chaque commit ultérieur est livré avec un filet de sécurité.