Un déploiement est effectué un vendredi à 16h. Les tests unitaires étaient au vert, le conteneur a été construit, le déploiement s'est terminé sans erreurs. Puis la file d'attente du support commence à se remplir : la caisse renvoie des erreurs 500. Le bug n'a jamais été dans le code testé. Il était dans la manière dont deux services communiquaient entre eux, et aucun test dans le pipeline n'a jamais exercé cette conversation.
C'est l'écart que l'automatisation des tests en DevOps est censée combler, et la partie dans laquelle la plupart des équipes sous-investissent est la couche API. Les tests unitaires prouvent qu'une fonction fonctionne de manière isolée. Les tests UI de bout en bout prouvent qu'un navigateur peut naviguer à travers un flux, lentement et de manière instable. Le contrat entre vos services, la chose qui tombe réellement en panne en production, se situe au milieu et reste souvent non vérifié. Les tests API se trouvent exactement là.
bouton
Ce que signifie réellement l'automatisation des tests en DevOps
DevOps est une boucle, pas une ligne. Planifier, coder, construire, tester, livrer, déployer, opérer, surveiller, puis revenir à la planification. L'automatisation des tests en DevOps signifie que les tests s'exécutent automatiquement aux points de cette boucle où ils détectent les problèmes au moindre coût, au lieu d'être une étape manuelle exécutée une seule fois avant une mise en production.
Le principe sous-jacent est le « shift-left » : déplacer les tests plus tôt, plus près du moment où un développeur écrit le changement. Un bug détecté sur une pull request coûte quelques minutes à corriger. Le même bug détecté en production coûte un rollback, un canal d'incident et un post-mortem. L'automatisation est ce qui rend le shift-left possible, car un humain ne peut pas relancer manuellement une suite de régression à chaque commit, mais un pipeline le peut.
L'erreur est de traiter « l'automatisation des tests » comme un seul bloc. La pyramide des tests la divise en couches, et chaque couche répond à une question différente :
- Les tests unitaires demandent si une seule fonction renvoie la bonne valeur. Ils sont rapides et nombreux.
- Les tests API et d'intégration demandent si vos services produisent des réponses correctes et communiquent correctement entre eux. Moins nombreux, mais chacun couvre un champ plus large.
- Les tests de bout en bout demandent si l'ensemble du système fonctionne du point de vue de l'utilisateur. Lents, fragiles et à maintenir en petit nombre.
Les tests API se situent au milieu, là où ils sont les plus productifs. Ils s'exécutent en secondes, pas en minutes. Ils ne dépendent pas d'une interface utilisateur rendue, donc ils ne se cassent pas lorsqu'un bouton se déplace. Et ils testent la surface dont vos autres services et vos clients dépendent réellement. C'est pourquoi, dans un pipeline DevOps, les tests API supportent une plus grande partie de la charge de détection des régressions que toute autre couche. Pour les fondements de la pratique elle-même, l'automatisation des tests API couvre ce qu'il faut affirmer et pourquoi avant de vous soucier de l'endroit où cela s'exécute.
Le cycle de vie DevOps, étape par étape, et où les tests API s'intègrent
Voici la carte pratique. Toutes les équipes n'ont pas besoin de tests API à chaque étape, mais connaître les options vous permet de choisir délibérément au lieu de tout déverser dans une seule tâche géante de pré-déploiement.
Pendant le développement : local et pré-commit
Avant qu'un changement n'atteigne la CI, un développeur devrait être en mesure d'exécuter les tests API pertinents contre un environnement local ou de développement. C'est la boucle de feedback la plus rapide dont vous disposez. Détecter une forme de réponse cassée ici signifie que le code défectueux n'est même jamais poussé.
En pratique, c'est le même scénario que vous exécuterez plus tard en CI, mais ciblé sur un environnement local. Vous le construisez une fois. Si vous n'en avez jamais créé, comment écrire des scénarios de test avec Apidog explique comment enchaîner les requêtes et extraire une valeur d'une réponse pour l'utiliser dans la suivante.
Sur les pull requests : la porte de fusion
C'est l'endroit le plus précieux pour les tests API, et celui que les équipes sautent le plus souvent. Lorsqu'une pull request est ouverte, le pipeline démarre le service, exécute vos scénarios API contre celui-ci, et signale un succès ou un échec comme vérification de statut. Une vérification échouée bloque la fusion.
La raison pour laquelle cela compte : le coût d'un bug augmente fortement plus il voyage loin. Une assertion échouée sur une PR est une correction de cinq minutes pour l'auteur, qui a encore le changement frais en tête. La même défaillance trouvée une semaine plus tard en staging est un projet d'archéologie. Placer des tests API sur la porte des PR est le seul changement qui déplace le plus de défauts vers la gauche (shift-left).
Après la construction, avant la publication : vérifications d'intégration et de contrat
Une fois l'artefact construit et déployé dans un environnement de staging ou d'intégration, exécutez une suite plus large. C'est là que vous testez le véritable câblage : le service de paiement accepte-t-il toujours le corps de requête du service de commande, la pagination renvoie-t-elle toujours le champ que votre client lit, un jeton d'authentification émis par un service est-il accepté par un autre.
Cette étape est aussi celle où la pensée contractuelle porte ses fruits. Un changement valide localement peut toujours casser un consommateur en aval. L'exécution de l'ensemble complet des scénarios sur un environnement intégré détecte les ruptures inter-services que les tests unitaires ne peuvent structurellement pas voir. Les modèles sont repris de la pratique plus large de l'automatisation des tests API.
Au moment du déploiement : tests de fumée
Un déploiement n'est pas terminé lorsque le déploiement est fini. Il est terminé lorsque vous avez la preuve que la nouvelle version sert réellement le trafic correctement. Un test de fumée est un scénario petit et rapide qui couvre les chemins critiques juste après le déploiement : un utilisateur peut-il s'authentifier, peut-il lire ses données, le point de terminaison critique pour la santé renvoie-t-il 200 avec la bonne forme.
Gardez cette suite petite et rapide. Son rôle est de donner un signal de validation ou de refus, pas de couverture. Si elle échoue, vous effectuez un rollback automatiquement. Exécutez le même scénario sur l'environnement de production en changeant un seul flag d'environnement, sans avoir à maintenir de test en double.
En production : surveillance continue
Après le déploiement, la boucle ne s'arrête pas. Les mêmes scénarios API que vous exécutez en CI peuvent être exécutés selon un calendrier sur la production comme surveillance synthétique, détectant une dépendance tierce dégradée ou un certificat expiré avant qu'un client ne le fasse. La frontière entre un test et un moniteur est principalement le calendrier d'exécution. La surveillance API couvre la transformation des tests réussis en un système d'alerte précoce pour la production.
Une règle pratique utile pour les cinq étapes : plus on est proche de la production, plus la suite est petite et rapide. Large couverture sur les PR et en intégration ; une suite de tests de fumée fine et impitoyable au déploiement et en surveillance.
Pourquoi la couche API gagne sa place dans le pipeline
Il est utile d'être concret sur les raisons pour lesquelles les tests API méritent une place de choix plutôt que d'alourdir davantage les tests UI.
Ils sont rapides. Un scénario API communique directement en HTTP. Pas de navigateur à lancer, pas de DOM à attendre, pas de Chrome headless qui plante sur un rendu lent. Un scénario qui exerce une douzaine de points de terminaison se termine en quelques secondes, ce qui vous permet de l'exécuter à chaque commit sans que les gens n'apprennent à ignorer une tâche de dix minutes.
Ils sont stables. Les tests UI se cassent lorsqu'un nom de classe change ou qu'un élément se re-rend avec un léger retard. Les tests API ne se cassent que lorsque le contrat réel change, ce qui est exactement le moment où vous voulez le savoir. Moins de fausses alarmes signifie que les gens font confiance à un build en échec, et un build auquel les gens font confiance est le seul qui puisse bloquer quoi que ce soit.
Ils testent ce qui s'intègre. Votre application mobile, vos intégrations partenaires, vos propres microservices dépendent tous du contrat API, et non de votre CSS. Lorsque ce contrat change silencieusement, chaque consommateur tombe en panne instantanément. Les tests API sont la couche qui détecte cela.
C'est pourquoi la question du pipeline est en réalité une question d'API. Vous pouvez avoir une suite unitaire complète et une jolie suite UI et quand même livrer le bug de la caisse du vendredi après-midi, car aucune des deux couches ne surveillait la jonction où les services se rencontrent.
Intégrer les tests API dans le pipeline avec l'Apidog CLI
La mécanique est importante, car un test qui existe mais ne s'exécute pas automatiquement ne détecte rien. Le modèle est le même dans chaque système de CI : installer un runner, le pointer vers vos tests, laisser son code de sortie décider si le build passe.
Avec Apidog, vous ne réécrivez pas vos tests en tant que code. Vous construisez le scénario une fois dans l'application, puis l'Apidog CLI exécute ce même scénario sans interface graphique (headless). La CLI est un package npm, donc tout runner CI avec Node.js peut l'utiliser.
Installez-le :
npm install -g apidog-cli
Ensuite, exécutez un scénario. Vous générez le jeton d'accès et trouvez les identifiants de scénario et d'environnement dans l'onglet CI/CD du scénario de test dans Apidog, qui construit la commande complète à copier pour vous :
apidog run \
--access-token $APIDOG_ACCESS_TOKEN \
-t 605067 \
-e 1629989 \
-r cli
Quelques éléments effectuent un travail réel ici. Le flag -t nomme le scénario par ID ; remplacez-le par -f <folderId> pour exécuter un dossier entier, ou --test-suite <id> pour exécuter une suite de tests sélectionnée comme une seule tâche. Le flag -e sélectionne l'environnement, ce qui permet au même scénario de bloquer une PR sur le staging et d'exécuter des tests de fumée sur la production sans duplication. Le flag -r choisit les reporters ; cli imprime dans le journal, et junit émet un XML que votre tableau de bord CI peut rendre comme rapport de test.
La partie qui en fait une porte est le code de sortie. Lorsque chaque assertion réussit, apidog run sort avec 0. Lorsque quelque chose échoue, il sort avec une valeur non nulle. Votre système de CI lit ce code, marque l'étape comme échouée et bloque la fusion ou le déploiement. Vous ne configurez pas de porte séparée ; le code de sortie est la porte. Exécutez apidog run --help pour voir la surface complète des options pour votre version.
Voici l'étape de la porte de PR intégrée dans GitHub Actions :
name: API Tests
on: [pull_request]
jobs:
api-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install Apidog CLI
run: npm install -g apidog-cli
- name: Run API scenarios
env:
APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
run: |
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t 605067 \
-e 1629989 \
-r cli,junit
Le jeton réside dans les secrets du dépôt et atteint l'étape via env:, jamais codé en dur. Le même bloc s'intègre dans GitLab CI, Jenkins, CircleCI ou Azure Pipelines avec la syntaxe de cette plateforme autour, car la seule dépendance réelle est Node. Les tutoriels spécifiques à chaque plateforme couvrent les détails : automatiser les tests API dans GitHub Actions et intégrer les tests Apidog avec Jenkins.
Pour l'étape de test de fumée au moment du déploiement, la commande ne change presque pas. Vous la pointez vers l'ID de l'environnement de production et gardez le scénario petit :
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e $PROD_ENV_ID -r cli
Un scénario, un échange d'environnement, deux tâches. C'est tout l'intérêt de créer des tests une seule fois et de les exécuter tout au long du cycle de vie.
Erreurs courantes qui déjouent discrètement la porte
Un pipeline peut sembler entièrement automatisé et pourtant ne rien détecter. Surveillez ces points.
Ignorer le code de sortie. Quelqu'un enveloppe la commande de test dans un pipeline shell ou ajoute || true pour « l'empêcher de casser le build ». Cela l'empêche également de détecter quoi que ce soit. Le build reste vert pour toujours. Ne masquez jamais la sortie non nulle du runner ; cette sortie est tout l'intérêt.
Ne tester que le chemin nominal. Un scénario qui confirme 200 OK et s'arrête là passe à côté des ruptures importantes. Affirmez sur la forme du corps de la réponse, les types de champs, les réponses d'erreur pour les mauvaises entrées. Les assertions API couvrent la validation de bien plus qu'un simple code de statut.
Une seule tâche géante de pré-déploiement. Entasser tous les tests dans une seule étape juste avant la publication annule le principe du shift-left. Vous découvrez un contrat cassé quelques minutes avant la livraison au lieu de le faire sur la PR. Répartissez la suite sur plusieurs étapes : large sur les PR, fine au déploiement.
Tester contre un environnement mutable partagé. Lorsque deux pipelines frappent la même base de données, les écritures d'une exécution corrompent les lectures d'une autre, et vous obtenez des échecs instables qui érodent la confiance. Utilisez des environnements isolés, ou utilisez le mocking API pour simuler les dépendances que vous ne contrôlez pas afin que le temps d'arrêt d'un tiers ne fasse pas échouer votre build.
Oublier le rapport en cas d'échec. Si votre rapport n'est téléchargé que lorsque les tests réussissent, vous ne verrez jamais le rapport la seule fois où vous en aurez besoin. Configurez le téléchargement de l'artefact pour qu'il s'exécute même en cas d'échec.
FAQ
Où les tests API devraient-ils s'exécuter dans le pipeline DevOps ?
Au minimum, sur les pull requests en tant que porte de fusion, car cela détecte le plus de défauts au coût le plus bas. Idéalement aussi après le build contre un environnement intégré pour les vérifications de contrat, et comme une petite suite de tests de fumée juste après le déploiement. Le même scénario Apidog s'exécute à chaque étape ; vous ne changez que le flag d'environnement. Les équipes utilisant Apidog sans Postman suivent la même mise en scène.
Quelle est la différence entre l'automatisation des tests API et le CI/CD ?
Le CI/CD est le pipeline qui construit, teste et livre votre code automatiquement. L'automatisation des tests API est un type de test qui s'exécute à l'intérieur de ce pipeline. Le CI/CD est le tapis roulant ; les tests API automatisés en sont une station de contrôle qualité. Si le terme CI/CD lui-même est flou, ce qu'est le CI/CD couvre les fondamentaux.
Dois-je réécrire mes tests API en tant que code pour les exécuter en CI ?
Pas avec Apidog. Vous construisez le scénario de test visuellement dans l'application, et l'Apidog CLI exécute ce même scénario sans interface graphique. La CLI est un package npm, donc tout runner CI avec Node.js installé peut l'exécuter avec une seule commande.
Comment les tests API font-ils échouer un build ?
Par le code de sortie. Lorsque chaque assertion dans un scénario réussit, le runner sort avec 0. Lorsqu'une assertion échoue, il sort avec une valeur non nulle. Le système CI lit ce code, marque l'étape comme échouée et bloque la fusion ou le déploiement. Aucune configuration de porte séparée n'est nécessaire.
Les tests de performance devraient-ils s'exécuter dans le même pipeline ?
Maintenez les tests API fonctionnels sur chaque PR et exécutez les tests de charge plus lourds et les tests de performance selon un calendrier séparé, comme toutes les nuits. Les exécutions de performance prennent plus de temps et nécessitent un environnement stable, donc les ajouter à chaque commit ralentit le feedback sans ajouter beaucoup de signal par commit.
Où placer votre premier test API
L'automatisation des tests en DevOps n'est pas une seule porte que l'on construit une fois. Ce sont des tests API délibérément placés tout au long de la boucle : sur la machine du développeur pour un feedback rapide, sur la pull request comme porte de fusion qui détecte le plus, après le build pour les vérifications de contrat, au moment du déploiement comme signal de fumée, et en production comme moniteur. La couche API gagne le plus de place dans le pipeline car elle est rapide, stable et teste la jonction où les systèmes tombent réellement en panne.
Si vos tests API existent toujours comme des étapes cliquables que quelqu'un exécute manuellement, l'écart à combler est la porte de fusion. Téléchargez Apidog, construisez un scénario, copiez la commande apidog run de son onglet CI/CD, et collez le bloc GitHub Actions ci-dessus. Vous aurez des tests API bloquant les fusions défectueuses d'ici la fin de l'après-midi, et le bug du déploiement du vendredi passera au rouge sur une pull request au lieu d'apparaître dans votre file d'attente de support.