12 Meilleures Pratiques CI/CD pour les Tests d'API Automatisés

Un pipeline vert qui déploie une API défectueuse est pire que pas de pipeline du tout. Il dit à votre équipe que tout va bien jusqu'à ce qu'un client dépose un ticket. La plupart des configurations de tests API en CI commencent fort et se dégradent en silence : quelques endpoints sont couverts, puis la suite devient instable, quelqu'un ajoute continue-on-error pour arrêter le bruit, et en un trimestre, les tests s'exécutent mais personne ne leur fait confiance. Le pipeline est vert parce qu'il a appris à ignorer les échecs.

La solution n'est pas plus de tests. Ce sont quelques décisions sur la façon dont vous concevez, exécutez et validez ces tests qui résistent à la pression du monde réel, celle qui vient d'un correctif d'urgence du vendredi après-midi ou d'un changement de schéma sur trois services en profondeur. Ce guide présente douze de ces décisions, avec des configurations concrètes que vous pouvez copier dans GitHub Actions, GitLab CI ou tout autre exécuteur que vous utilisez déjà.

Le fil conducteur de toutes ces décisions est le même : vos tests API doivent vivre à côté de votre contrat API, s'exécuter à partir d'une commande portable unique, et échouer bruyamment lorsque le contrat est rompu. C'est le flux de travail que nous construirons avec Apidog, une plateforme API où vous concevez la spécification, écrivez des assertions visuellement, et exécutez l'ensemble de la suite sans interface graphique en CI via l'interface en ligne de commande (CLI) d'Apidog. Vous concevez les tests une fois dans l'application, puis exécutez cette suite exacte dans n'importe quel pipeline avec une seule commande. Si vous souhaitez suivre, téléchargez Apidog et gardez votre propre API à portée de main.

Si la CI/CD elle-même est nouvelle pour vous, la version courte est la suivante : l'intégration continue exécute vos tests à chaque commit, et la livraison continue promeut la build qui les réussit. Nous avons une explication plus complète dans Qu'est-ce que la CI/CD et comment ça marche. Le reste de cet article suppose que vous avez un pipeline et que vous voulez que la partie test API y gagne réellement sa place.

1. Mettez les tests API dans le pipeline, pas dans un onglet que vous avez oublié d'ouvrir

La première meilleure pratique est celle que les gens ignorent : exécutez vos tests API automatiquement, à chaque push, sans qu'un humain n'ait à le décider. Une suite de tests que vous exécutez manuellement avant une publication est une liste de contrôle, pas un filet de sécurité. Au moment où vous vous souvenez de l'exécuter, le changement qui a causé les problèmes est déjà six commits en arrière.

Intégrez la suite dans l'étape qui compte. Pour la plupart des équipes, c'est sur les pull requests, de sorte qu'une API défectueuse bloque la fusion au lieu d'atteindre main. Voici la forme minimale dans GitHub Actions :

name: API Tests
on:
  pull_request:
    branches: [main]
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 test suite
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t "$SCENARIO_ID" \
            -e "$APIDOG_ENV_ID" \
            -r cli,junit \
            --out-dir ./test-results
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
          SCENARIO_ID: ${{ vars.SCENARIO_ID }}
          APIDOG_ENV_ID: ${{ vars.APIDOG_ENV_ID }}

C'est l'intégration complète. La CLI renvoie 0 lorsque toutes les assertions passent et un code non nul lorsque l'une d'elles échoue, de sorte que GitHub met le job en rouge en cas de véritable échec sans câblage supplémentaire. Nous couvrons la configuration complète de GitHub dans Comment automatiser les tests API dans GitHub Actions ; le modèle s'applique à tout exécuteur.

Le but de la première bonne pratique est que la décision de tester soit prise par la machine, et non par le développeur. Les humains oublient. Les pipelines non.

2. Gardez la commande d'exécution portable entre les fournisseurs de CI

Les pipelines migrent. Les équipes passent de Jenkins à GitHub Actions, ajoutent GitLab pour un nouveau dépôt, ou lancent un exécuteur auto-hébergé pour la conformité. Si vos tests API sont soudés à l'écosystème de plugins d'un fournisseur, chaque migration signifie les réécrire.

Pour éviter cela, il faut faire de l'invocation de test une seule commande shell que n'importe quel exécuteur peut appeler. Avec l'interface en ligne de commande Apidog, la commande qui exécute votre suite est identique quel que soit l'invocateur :

apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$SCENARIO_ID" -e "$ENV_ID" -r cli,junit

Cette même ligne fonctionne dans une étape run de GitHub Actions, un bloc script de GitLab, une étape shell de Jenkins ou une section script de Travis. Seul l'enveloppe autour d'elle change. GitLab, par exemple :

api-tests:
  image: node:20
  script:
    - npm install -g apidog-cli
    - apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$SCENARIO_ID" -e "$ENV_ID" -r cli,junit
  artifacts:
    when: always
    reports:
      junit: ./test-results/*.xml

Parce que le gros du travail (orchestration des requêtes, assertions, résolution d'environnement) réside dans la CLI et que les définitions de test résident dans Apidog, votre fichier YAML de pipeline reste léger. Lorsque vous changez de fournisseur, vous copiez six lignes, pas six cents. La variante Jenkins est détaillée dans Comment intégrer les tests automatisés Apidog à Jenkins pour la CI/CD si c'est votre pile.

3. Faites des assertions sur le comportement, pas seulement sur les codes de statut

Un test qui ne vérifie que le statut 200 OK passera même si votre API renvoie un tableau vide, la mauvaise devise ou un nul là où le client attend un objet. Les tests basés uniquement sur le code de statut sont la principale raison pour laquelle les pipelines verts livrent des réponses défectueuses.

Les assertions réelles vérifient la forme et le contenu de la réponse : les champs qui existent, leurs types, les valeurs qui comptent pour un consommateur. Dans Apidog, vous les construisez visuellement par rapport à la réponse, de sorte que vous affirmez sur la charge utile réelle plutôt que de deviner un JSONPath dans votre tête. Un test de recherche de commande solide affirme que le statut est 200, que le order.total est un nombre, que la currency est égale à la valeur que vous avez envoyée, et que le tableau items n'est pas vide. Chacune d'elles est une assertion distincte qui échoue indépendamment, de sorte qu'une build rouge vous indique quel contrat a été rompu.

Trois règles permettent aux assertions de tenir dans le temps :

• Affirmer sur le contrat, pas sur les données. Vérifiez que total est un nombre, pas qu'il est égal à 49.99. La valeur exacte change ; le type non.
• Une seule préoccupation par assertion. Regrouper six vérifications en une seule assertion masque laquelle a échoué.
• Couvrir le chemin non souhaité. Un 400 sur une mauvaise entrée et un 401 sur un jeton manquant font également partie de votre contrat. Testez qu'ils se comportent toujours comme prévu.

Pour un traitement plus approfondi de la rédaction d'assertions qui survivent aux refactorisations, consultez notre guide sur les assertions API. Des assertions solides transforment un test de fumée en test de contrat, et les tests de contrat sont ce qui détecte les régressions qui comptent.

4. Gérez les environnements et les secrets comme des configurations, jamais comme des valeurs codées en dur

Vos tests s'exécutent sur différentes cibles : une pile locale, une API de staging, un endpoint de fumée de production. L'URL de base, les jetons d'authentification et les ID de locataire changent tous entre eux. Coder en dur l'un de ces éléments dans un test est la façon dont un test de staging frappe accidentellement la production, ou comment un jeton se retrouve dans votre historique Git.

Gardez les environnements comme des configurations nommées et injectez les différences. Dans Apidog, un environnement contient l'URL de base et les variables pour une cible ; vous choisissez celui qu'une exécution CI utilise avec le drapeau -e. Le pipeline fournit le jeton d'accès depuis son magasin de secrets, jamais depuis un fichier dans le dépôt :

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t "$SCENARIO_ID" \
  -e "$STAGING_ENV_ID" \
  -r cli,junit

Le même scénario, ciblé sur une valeur -e différente, devient votre test de fumée de production. Rien ne change dans le test ; seul l'environnement par rapport auquel il se résout change. Stockez APIDOG_ACCESS_TOKEN dans les Secrets GitHub, les variables CI/CD GitLab ou le gestionnaire de références de votre exécuteur, et référencez-le par son nom. La règle est simple : tout ce qui diffère entre les environnements ou tout ce qui est secret est une configuration, et la configuration est injectée au moment de l'exécution.

5. Rendez les tests déterministes pour que le pipeline soit digne de confiance

Un test instable est un test qui échoue pour des raisons sans rapport avec votre code. C'est aussi le moyen le plus rapide de détruire la crédibilité d'un pipeline. Une fois qu'une suite "échoue parfois", les développeurs commencent à relancer les jobs jusqu'à ce qu'ils passent au vert, ce qui signifie qu'un véritable échec se cache désormais dans le bruit des faux.

La plupart de l'instabilité des tests API provient de quelques sources prévisibles :

• État mutable partagé. Deux tests créant un utilisateur avec le même e-mail, ou un test dépendant de données supprimées par un autre test. Chaque test doit configurer et nettoyer ses propres données, ou utiliser des locataires isolés.
• Hypothèses de synchronisation. Assertion sur un résultat asynchrone avant qu'il ne soit prêt. Si une opération est éventuelle, interrogez la condition au lieu de dormir un nombre fixe de secondes.
• Dépendances réelles que vous ne contrôlez pas. Un bac à sable de paiement tiers qui vous impose des limites de taux, ou un service en amont en maintenance. Moquez ces limites afin que votre test mesure votre API, pas la disponibilité de quelqu'un d'autre. Apidog peut créer une maquette pour une dépendance instable à partir de son schéma, ce qui éloigne l'instabilité externe de votre build.
• Dépendance à l'ordre. Tests qui ne passent que lorsqu'ils sont exécutés dans une séquence spécifique. Une suite doit passer quel que soit l'ordre d'exécution, car les exécuteurs parallélisent.

Le déterminisme est la différence entre un pipeline que les gens respectent et un autre qu'ils contournent. Investissez-y de l'ingénierie tôt ; les tests instables accumulent les intérêts.

6. Gardez l'étape de test API rapide, sinon les développeurs la contourneront

Une suite de tests qui prend vingt minutes à chaque pull request devient une taxe que les développeurs vont finir par détester et désactiver. La vitesse n'est pas un luxe en CI ; c'est ce qui permet à la suite de fonctionner tout court. L'objectif que la plupart des équipes visent est une étape API de moins de cinq minutes sur les PRs.

Quelques leviers pour y parvenir :

• Exécutez des scénarios indépendants en parallèle. Si vos tests sont déterministes (meilleure pratique cinq), rien ne vous empêche de les répartir sur des jobs parallèles ou de laisser l'exécuteur les distribuer. Les suites indépendantes peuvent s'exécuter côte à côte.
• Hiérarchisez vos tests. Exécutez une suite de fumée rapide sur chaque PR et la suite de régression complète sur la fusion vers main ou selon un calendrier nocturne. Tous les tests n'ont pas besoin de bloquer chaque commit.
• Mettez l'installation en cache. La mise en cache de l'installation npm globale de apidog-cli entre les exécutions réduit le temps de configuration de chaque job.
• Échouez rapidement là où cela aide, terminez là où cela n'aide pas. Sur une PR, arrêtez-vous à la première défaillance pour donner un feedback rapide. Sur une exécution nocturne complète, utilisez l'option --on-error continue de la CLI afin qu'un endpoint défectueux ne cache pas les quarante autres qui ont également échoué.

Voici le modèle hiérarchisé dans GitHub Actions, avec une exécution rapide de fumée sur les PRs et la suite complète selon un calendrier :

on:
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 2 * * *'   # nightly full regression

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g apidog-cli
      - name: Run suite
        run: |
          if [ "${{ github.event_name }}" = "pull_request" ]; then
            apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$SMOKE_ID" -e "$ENV_ID" -r cli,junit --out-dir ./test-results
          else
            apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$FULL_ID" -e "$ENV_ID" -r cli,junit --on-error continue --out-dir ./test-results
          fi
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

Une étape rapide qui s'exécute vaut plus qu'une étape approfondie qui est désactivée.

7. Publiez des résultats lisibles par machine, pas seulement un mur de texte console

Lorsqu'une build échoue, "les tests API ont échoué" ne suffit pas. Vous devez savoir quelle assertion a échoué, dans quel scénario, sur quelle requête. Une build rouge avec un millier de lignes de sortie console est à peine meilleure que pas de test du tout ; quelqu'un doit encore la lire.

La solution consiste à émettre des résultats dans un format que votre serveur CI analyse nativement. JUnit XML est le format standard des résultats de tests CI, et presque toutes les plateformes le lisent. La CLI Apidog en écrit un avec le rapporteur junit :

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t "$SCENARIO_ID" \
  -e "$ENV_ID" \
  -r cli,html,junit \
  --out-dir ./test-results

Cette commande émet trois vues de la même exécution : cli pour la sortie console en direct, html pour un rapport consultable qu'un humain peut ouvrir, et junit pour la machine. Pointez votre pipeline vers le XML et la plateforme le transforme en résultats structurés, par test :

      - name: Publish test report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: api-test-results
          path: ./test-results

Notez le if: always(). Vous voulez que le rapport soit publié même lorsque l'exécution échoue, car une exécution échouée est précisément le moment où vous en avez besoin. Le gain est réel : au lieu de "la build API est cassée", vous obtenez "l'assertion cart-total dans le scénario de paiement a commencé à échouer", ce qui transforme une session de débogage en un coup d'œil.

8. Bloquez les fusions sur la suite avec la protection de branche

Une suite de tests qui réussit mais qui ne bloque rien n'est qu'une notification. Le but de la CI est de rendre le code cassé non fusionnable, et cela nécessite une étape de plus que la plupart des équipes ne configurent : la protection de branche.

Le code de sortie fait le travail local. Parce que la CLI Apidog renvoie un code non nul en cas d'assertion échouée, le job passe au rouge en cas de véritable échec. Mais un job rouge sur une PR n'est qu'un avis tant que vous ne rendez pas la vérification obligatoire. Dans GitHub, définissez la vérification des tests API comme une vérification de statut requise sur main ; le bouton de fusion reste désactivé tant qu'il n'est pas vert. GitLab et Bitbucket ont l'équivalent dans leurs paramètres de demande de fusion.

C'est la différence entre une suite qui détecte les régressions et une qui les documente après coup. Sans une vérification obligatoire, un développeur sous la pression des délais clique sur fusionner et l'API cassée est déployée avec une vérification rouge juste à côté. Avec la barrière, la plateforme refuse. Le test cesse d'être une suggestion et devient une règle que les outils appliquent pour vous.

Associez cela aux résultats lisibles par machine de la meilleure pratique sept et à une intégration du statut de commit, et votre hôte Git affiche la vérification exacte échouée en ligne sur la PR. La boucle de rétroaction se referme : push, test, bloqué, correction, vert, fusion.

9. Générez la couverture de test à partir de votre spécification API au lieu de l'écrire à la main

La partie la plus lente des tests API est de maintenir les tests synchronisés avec l'API. Chaque nouveau point de terminaison nécessite un nouveau test ; chaque champ modifié nécessite une assertion mise à jour. Fait à la main, les tests sont toujours en retard sur l'API, et l'écart est l'endroit où les régressions vivent.

L'astuce est de piloter les tests à partir du contrat. Si votre API a une spécification OpenAPI, vous pouvez en générer l'échafaudage de test : une requête par point de terminaison, avec le schéma décrivant déjà la forme de réponse attendue. Dans Apidog, la spécification et les tests vivent dans le même espace de travail, de sorte qu'un scénario de test peut être construit directement à partir des points de terminaison documentés plutôt que d'être transcrit à partir d'eux. Nous expliquons le flux de génération dans Comment générer des collections de tests API à partir de spécifications OpenAPI.

Cela compte en CI parce que les tests pilotés par spécification détectent un bug spécifique et courant : la dérive entre ce que vos documents promettent et ce que votre API renvoie. Lorsque le test est généré à partir de la spécification et exécuté par rapport à l'API en direct, une non-concordance fait échouer la build. Le contrat devient exécutable. Vous écrivez toujours les assertions qui encodent le sens métier à la main, mais vous n'écrivez pas à la main le boilerplate de "cet endpoint existe-t-il et renvoie-t-il la forme documentée". Laissez la spécification porter ce poids.

10. Utilisez des tests basés sur les données pour couvrir les cas limites sans dupliquer les scénarios

Le même point de terminaison se comporte différemment selon les entrées : une commande valide, une commande dépassant la limite de crédit, une commande avec un SKU inconnu, une commande dans une devise non prise en charge. Écrire un scénario distinct pour chacun d'eux fait gonfler les suites en centaines de tests quasi identiques que personne ne maintient.

Les tests basés sur les données exécutent un scénario par rapport à de nombreuses lignes d'entrée. Vous définissez la requête et les assertions une fois, puis alimentez un tableau de cas. La CLI Apidog prend un fichier de données avec le drapeau -d :

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t "$SCENARIO_ID" \
  -e "$ENV_ID" \
  -d ./test-data/orders.csv \
  -r cli,junit \
  --out-dir ./test-results

Chaque ligne dans orders.csv devient une itération avec son propre succès ou échec. Un scénario, une invocation CLI, une couverture complète des cas limites, et un rapport JUnit qui montre quelles lignes d'entrée ont échoué. Cela maintient votre suite petite et votre couverture large, ce qui est exactement le compromis que vous voulez en CI. Notre guide sur les tests API basés sur les données avec CSV ou JSON approfondit la structuration du fichier de données.

Ce modèle est le plus efficace pour la logique de validation et les règles de tarification, les endroits où un seul point de terminaison a le plus de branches et le plus de façons de régresser silencieusement.

11. Exécutez un test de fumée post-déploiement contre l'environnement réel

Les tests qui passent en staging vous disent que la build est bonne. Ils ne vous disent pas que le déploiement a fonctionné. Dérive de configuration, variable d'environnement manquante, équilibreur de charge mal routé, certificat expiré : tous ces éléments passent chaque test de pré-fusion et ne se cassent que dans l'environnement que vous avez réellement déployé.

La protection est un test de fumée qui s'exécute après le déploiement, contre la cible en direct. C'est une suite petite et rapide, juste les chemins critiques, votre flux d'authentification, vos points de terminaison de lecture et d'écriture les plus importants, pointée vers la production ou l'environnement fraîchement déployé. Parce que la commande d'exécution est portable (meilleure pratique deux) et que les environnements ne sont que de la configuration (meilleure pratique quatre), c'est la même suite avec un -e différent :

  smoke-after-deploy:
    needs: deploy
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g apidog-cli
      - name: Smoke test production
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t "$SMOKE_SCENARIO_ID" \
            -e "$PROD_ENV_ID" \
            -r cli,junit \
            --out-dir ./smoke-results
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

Si le test de fumée échoue, c'est votre signal pour annuler avant que les utilisateurs ne le remarquent. Pour les équipes qui exécutent des déploiements bleu-vert ou canary, vous exécutez la suite de fumée contre la nouvelle couleur avant de rediriger le trafic vers elle, afin que votre premier véritable utilisateur ne soit jamais celui qui découvre le déploiement cassé. Le coût est d'une minute de temps de pipeline. L'alternative est de le découvrir via un ticket de support.

12. Traitez la suite de tests comme du code que vous maintenez, pas comme une configuration que vous terminez

La dernière bonne pratique est un état d'esprit. Une suite de tests CI n'est pas un projet que l'on termine ; c'est un actif que l'on maintient parallèlement à l'API qu'elle protège. Les équipes dont les pipelines restent fiables sont celles qui traitent un test instable comme un bug, une étape lente comme une dette technique, et un manque de couverture comme une régression en attente.

Quelques habitudes maintiennent une suite en bonne santé à long terme :

• Ajoutez le test avec la fonctionnalité. Un nouveau point de terminaison est livré avec son scénario dans la même PR, pas dans un suivi qui n'arrive jamais.
• Corrigez les instabilités le jour où elles apparaissent. Un test instable mis en quarantaine est un manque de couverture avec un voyant vert allumé. Ne laissez pas continue-on-error devenir permanent.
• Examinez ce que la suite ne couvre pas. Vérifiez périodiquement quels points de terminaison n'ont pas d'assertions. Ceux qui ne sont pas testés sont là où commence la prochaine panne.
• Gardez la configuration du pipeline sous contrôle de version. Votre YAML, vos définitions d'environnement et vos données de test vivent tous dans le dépôt, examinés comme tout autre changement.

Parce que les définitions de test vivent dans Apidog et que le pipeline ne contient qu'une invocation légère, la majeure partie de cette maintenance se fait là où c'est facile : vous ajoutez des scénarios et des assertions dans l'application, et la configuration CI change à peine. Les équipes qui réussissent cela passent leur temps à améliorer la couverture, et non à surveiller le YAML. Pour une vue plus large de l'organisation des grandes suites, consultez Suites de tests Apidog : une façon plus intelligente d'automatiser les tests API.

Mise en pratique

Ces douze pratiques se renforcent mutuellement. Les commandes d'exécution portables rendent les tests de fumée post-déploiement triviaux. Les tests déterministes rendent le parallélisme sûr, ce qui maintient l'étape rapide, ce qui incite les développeurs à l'utiliser. Les résultats lisibles par machine rendent la protection de branche significative, car la barrière pointe vers une vérification spécifique échouée au lieu d'un mur de texte. Les tests basés sur la spécification et les données maintiennent la suite complète sans la rendre lente à maintenir.

Le fondement commun est de garder vos tests proches de votre contrat et exécutables à partir d'une seule commande. C'est le flux de travail Apidog en une phrase : concevez l'API et ses tests au même endroit, puis exécutez cette suite exacte dans n'importe quel pipeline avec apidog run. La CLI renvoie un code non nul en cas d'échec, émet du JUnit pour que votre CI l'analyse, et se comporte de la même manière que GitHub Actions, GitLab, Jenkins ou un exécuteur auto-hébergé l'appelle.

Commencez petit. Intégrez un scénario critique dans votre pipeline de PR avec des assertions réelles et une vérification de statut obligatoire. Rendez cette boucle fiable, puis ajoutez le reste : exécutions échelonnées, cas limites basés sur les données, un test de fumée post-déploiement. Un pipeline auquel vous faites confiance est un pipeline qui passe au rouge uniquement lorsque quelque chose est réellement cassé, et au vert uniquement lorsqu'il est réellement sûr de déployer. Téléchargez Apidog et construisez le premier scénario dès aujourd'hui.

FAQ

Quelle est la différence entre les tests API en CI et la CI/CD ? La CI (intégration continue) exécute vos tests API automatiquement à chaque commit ou pull request pour détecter rapidement les régressions. La CD (livraison continue) promeut une build vers une cible de déploiement une fois qu'elle a passé ces vérifications. Les tests API se situent dans les deux : une suite pré-fusion bloque l'intégration, et une suite de fumée post-déploiement vérifie la livraison. La même commande Apidog CLI sert les deux étapes.

Dois-je écrire du code pour exécuter des tests API dans un pipeline ? Non. Vous construisez les requêtes et les assertions visuellement dans Apidog, puis vous les exécutez sans interface graphique avec une seule commande apidog run. Le pipeline n'a besoin que de cette seule commande, ce qui maintient votre configuration CI légère et signifie que les ingénieurs QA peuvent gérer les tests sans maintenir un framework basé sur le code. Le guide complet se trouve dans Comment automatiser les tests API en CI/CD.

Comment éviter que mes tests API ne soient instables en CI ? Les trois principales causes sont les données de test mutables partagées, les hypothèses de synchronisation sur les opérations asynchrones et les dépendances tierces non contrôlées. Donnez à chaque test ses propres données, interrogez les conditions asynchrones au lieu de dormir un temps fixe, et moquez les limites externes que vous ne contrôlez pas. Une suite qui passe dans n'importe quel ordre et à chaque exécution est l'objectif.

Comment faire en sorte qu'un test API échoué bloque une fusion ? Deux éléments. Premièrement, l'exécuteur de tests doit sortir avec un code non nul en cas d'échec ; la CLI Apidog le fait sur toute assertion échouée, de sorte que le job passe automatiquement au rouge. Deuxièmement, marquez ce job comme une vérification de statut requise dans les règles de protection de branche de votre hôte Git. Le bouton de fusion reste désactivé tant que la vérification ne passe pas.

Puis-je exécuter les mêmes tests API dans GitHub Actions, GitLab et Jenkins ? Oui. Parce que la logique de test réside dans Apidog et que le pipeline ne fait qu'appeler apidog run, la commande est identique d'un fournisseur à l'autre ; seul le script YAML ou de pipeline environnant change. Cette portabilité fait que la migration des fournisseurs CI est une modification de six lignes au lieu d'une réécriture. Consultez Comment automatiser les tests API dans GitHub Actions pour la configuration spécifique à GitHub.

Quelle doit être la rapidité de mon étape de test API ? Visez moins de cinq minutes sur les pull requests. Pour y parvenir, exécutez une suite de fumée rapide sur les PRs et la suite de régression complète chaque nuit, parallélisez les scénarios indépendants et mettez en cache l'installation de la CLI. Une étape lente est une étape que les développeurs finiront par désactiver, ce qui va à l'encontre de l'objectif.