Comment exécuter des tests API automatisés dans TeamCity ?

Votre API passe tous les tests sur votre ordinateur portable. Ensuite, un coéquipier fusionne une branche qui renomme un champ, et personne ne s'en aperçoit avant qu'un client mobile ne commence à planter en production. Les tests manuels l'ont manqué car personne n'a relancé la suite. C'est précisément cette lacune que l'intégration continue est conçue pour combler, et TeamCity est l'un des outils les plus puissants pour y parvenir.

TeamCity, le serveur CI/CD de JetBrains, exécute votre pipeline de build à chaque fois que du code est livré. Il peut compiler, tester, packager et déployer sans que personne n'ait à cliquer sur un bouton. L'étape que les équipes sautent souvent est l'intégration de vrais tests d'API dans ce pipeline. Ils testent les unités, ils testent la compilation du build, et ils déploient l'API avec confiance. Un champ renommé, une erreur 500 sur un cas limite, un flux d'authentification cassé ; rien de tout cela n'apparaît tant qu'un humain n'interroge pas le point de terminaison.

Ce guide vous explique comment exécuter des tests d'API automatisés dans TeamCity de bout en bout. Vous concevrez et validerez vos tests dans Apidog, puis les exécuterez sans interface graphique via la CLI Apidog en tant qu'étape de build TeamCity. Le résultat est un pipeline qui échoue la build dès que votre API ne se comporte plus correctement, avant qu'une mauvaise réponse n'atteigne un utilisateur.

Ce que vous allez construire

À la fin, vous aurez :

• Un projet TeamCity connecté à votre dépôt Git
• Une configuration de build avec un déclencheur VCS qui s'active à chaque push
• Une étape de build qui exécute votre suite de tests d'API via la CLI Apidog
• Des résultats de tests analysés visibles dans l'onglet Tests de TeamCity
• Une build qui devient rouge et bloque la fusion lorsqu'un point de terminaison est cassé

Le même modèle fonctionne pour un petit service interne ou une API publique avec des centaines de points de terminaison. Vous le faites évoluer en ajoutant des scénarios de test dans Apidog, et non en modifiant le code du pipeline.

Pourquoi les tests d'API doivent être dans TeamCity, et pas seulement sur votre machine

Les tests locaux ont un défaut fatal : ils dépendent de la mémoire de quelqu'un pour les exécuter. La CI élimine l'humain de la boucle. Chaque commit déclenche la même suite, dans le même environnement, avec les mêmes assertions. Il n'y a pas de « ça marche sur ma machine » car il n'y a pas de machine ; il y a un agent de build qui exécute les étapes exactes que vous avez définies.

TeamCity est bien adapté à cela pour plusieurs raisons concrètes :

• Chaînes de build. Vous pouvez faire en sorte que l'étape de test d'API dépende d'une étape de déploiement vers un environnement de staging, afin que les tests s'exécutent toujours sur une build fraîchement déployée, jamais sur une version obsolète.
• Historique des tests. TeamCity suit quels tests ont réussi et échoué à travers des centaines de builds. Lorsqu'un test commence à être instable, vous voyez exactement quel commit l'a introduit.
• Investigation et mise en sourdine. Un point de terminaison instable peut être mis en sourdine et assigné à un propriétaire au lieu de bloquer les fusions de tout le monde.
• Pools d'agents. Les suites lourdes s'exécutent sur des agents dédiés afin qu'elles ne ralentissent pas vos builds de compilation.

Le problème est que TeamCity ne sait pas comment appeler votre API ou vérifier la réponse. Il exécute la commande que vous lui donnez. Le vrai travail consiste donc à produire une seule commande qui exécute l'intégralité de votre suite d'API et se termine avec un code non nul lorsque quelque chose échoue. C'est là que la conception des tests est importante.

Étape 1 : Concevez et validez vos tests d'API dans Apidog

Avant que quoi que ce soit ne touche TeamCity, vous avez besoin de tests qui s'exécutent réellement sans surveillance. Un test qui vous demande de vérifier visuellement une réponse JSON est inutile en CI. Chaque vérification doit être une assertion que la machine peut évaluer : le code de statut est 200, le champ id est un nombre, la réponse est revenue en moins de 800 ms.

Apidog est conçu précisément pour cela. Vous concevez la requête, puis y attachez des assertions d'API qui valident automatiquement la réponse ; codes de statut, conformité au schéma JSON, valeurs de champ spécifiques, temps de réponse. Vous pouvez enchaîner des requêtes dans un scénario afin que la sortie d'un appel de connexion alimente le jeton dans la requête suivante. Aucun script n'est requis pour les cas courants, et un script complet est disponible lorsque vous en avez besoin.

Un scénario réaliste pour une API e-commerce pourrait ressembler à ceci :

1. POST /auth/login avec des identifiants de test, affirmer 200, extraire le jeton d'authentification dans une variable.
2. GET /products?category=books avec ce jeton, affirmer 200, affirmer que la réponse est un tableau, affirmer que chaque article a un prix supérieur à 0.
3. POST /cart/items avec un ID de produit, affirmer 201, affirmer que le total du panier renvoyé correspond au prix de l'article.
4. GET /cart, affirmer que le nombre d'articles est 1.

Chaque étape a des assertions qui passent ou échouent de manière autonome. Exécutez le scénario dans Apidog d'abord et confirmez qu'il passe au vert par rapport à votre environnement de staging. S'il ne peut pas passer lorsque vous l'exécutez à la main, il ne passera jamais en CI. Regroupez les scénarios liés dans une suite de tests afin de pouvoir exécuter le tout avec une seule commande au lieu de scénario par scénario.

L'avantage de construire des tests de cette manière est que les mêmes scénarios que vous utilisez pour le débogage manuel deviennent votre suite CI. Vous ne maintenez pas deux ensembles de tests parallèles ; un dans une interface graphique pour l'exploration, un dans le code pour l'automatisation. C'est une seule source de vérité. Si vous venez d'un framework axé sur le code comme REST Assured, c'est la partie qui vous fait gagner le plus de temps : vous arrêtez d'écrire et de réécrire du code passe-partout de requête/assertion pour chaque point de terminaison.

Téléchargez Apidog si vous voulez suivre. C'est gratuit pour commencer, et la CLI fait partie de la même chaîne d'outils.

Étape 2 : Faites d'abord fonctionner la CLI Apidog localement

Ne débuguez jamais une nouvelle commande pour la première fois en CI. La boucle de rétroaction dans un serveur CI est brutale ; vous poussez, attendez un agent, lisez un journal, corrigez un caractère, poussez à nouveau. Prouvez que la commande fonctionne sur votre machine, puis copiez la version fonctionnelle dans TeamCity.

La CLI Apidog fonctionne avec Node.js, alors installez-la globalement avec npm :

npm install -g apidog-cli

Confirmez sa présence :

apidog --version

Maintenant, exécutez votre scénario de test. La CLI peut exécuter un scénario ou une suite directement depuis votre projet Apidog en référençant son ID, authentifié avec un jeton d'accès, ou depuis un fichier exporté localement. L'approche en ligne maintient vos tests comme source unique de vérité ; tout ce que votre équipe modifie dans Apidog est ce qui s'exécute en CI, sans étape d'exportation à oublier.

Générez un jeton d'accès depuis les paramètres de votre compte Apidog, puis exécutez :

apidog run \
 --access-token "$APIDOG_ACCESS_TOKEN" \
 -e "$APIDOG_ENV_ID" \
 -r cli,html,junit

Quelques points à noter ici :

• --access-token authentifie l'exécution. Passez-le en ligne comme ceci, ou connectez-vous une fois avec apidog login --with-token.
• -e sélectionne l'environnement sur lequel exécuter les tests ; staging, production-lecture seule, tout ce que vous avez défini dans Apidog. Vous dirigez les mêmes tests vers différentes URL de base en changeant cet ID.
• -r choisit les rapports. cli affiche une sortie lisible par l'homme dans la console, html produit un rapport que vous pouvez parcourir, et un rapport au format JUnit est ce qui permet à TeamCity d'analyser et d'afficher les résultats de tests individuels.

Lorsque l'exécution se termine, la CLI quitte avec 0 si tout s'est bien passé et avec un code non nul si une assertion a échoué. Ce code de sortie est tout l'enjeu en CI : une sortie non nulle indique à TeamCity de marquer la build comme ayant échoué.

Pour les tests qui doivent s'exécuter sur de nombreuses entrées, la CLI prend en charge les exécutions pilotées par les données. Pointez-la vers un fichier CSV ou JSON et elle itère le scénario une fois par ligne :

apidog run \
 --access-token "$APIDOG_ACCESS_TOKEN" \
 -d test-data/checkout-cases.csv \
 -r cli,junit

C'est ainsi que vous testez une centaine d'ID de produits ou un tableau de charges utiles invalides sans écrire une centaine de scénarios. Chaque ligne devient sa propre itération avec son propre résultat de réussite/échec.

Une fois que vous voyez une sortie verte localement, vous avez une commande en laquelle vous avez confiance. Copiez-la. C'est cette commande exacte qui ira dans TeamCity.

Étape 3 : Connectez TeamCity à votre dépôt

Maintenant, passez à TeamCity. L'objectif de cette étape est de donner un projet à TeamCity, de le diriger vers votre code et de le laisser déclencher des builds à chaque push.

Si vous utilisez TeamCity pour la première fois, le chemin le plus simple est l'image Docker officielle. Elle vous permet d'avoir un serveur fonctionnel en quelques minutes :

docker run -d --name teamcity-server \
 -v ~/teamcity/datadir:/data/teamcity_server/datadir \
 -v ~/teamcity/logs:/opt/teamcity/logs \
 -p 8111:8111 \
 jetbrains/teamcity-server

Ouvrez http://localhost:8111, complétez la configuration initiale (choix de la base de données, compte admin), et vous arrivez sur le tableau de bord. Les configurations de production utilisent une base de données externe appropriée et des agents de build dédiés, mais pour suivre ce guide, l'agent intégré est suffisant.

Créez le projet :

1. Allez dans Administration et choisissez Créer un projet.
2. Choisissez À partir d'une URL de dépôt et collez votre dépôt Git distant (HTTPS ou SSH).
3. Ajoutez des identifiants si le dépôt est privé ; une clé de déploiement ou un jeton d'accès personnel.
4. TeamCity scanne le dépôt et doit détecter automatiquement les étapes de build. Vous pouvez le laisser faire, mais pour les tests d'API, il est plus propre de configurer l'étape vous-même dans la section suivante.

TeamCity crée une racine VCS (sa connexion à votre dépôt) et une configuration de build (l'ensemble des étapes qui s'exécutent). Une fois la racine VCS en place, configurez le déclencheur pour que les builds se lancent automatiquement :

1. Ouvrez votre configuration de build et allez dans Déclencheurs.
2. Ajoutez un Déclencheur VCS.
3. Laissez la règle par défaut afin que chaque modification de la branche surveillée mette une build en file d'attente.

À partir de là, chaque push vers votre dépôt déclenchera une build. Pour l'instant, cette build ne fait rien d'utile ; l'étape suivante lui donne la commande de test d'API.

Étape 4 : Ajoutez la CLI Apidog comme étape de build

C'est le cœur de la configuration. Vous ajoutez une étape de build qui installe la CLI sur l'agent et exécute votre suite.

Dans votre configuration de build, ouvrez Étapes de build et ajoutez une nouvelle étape de type Ligne de commande. Choisissez Script personnalisé et collez :

#!/bin/bash
set -e

# Install the Apidog CLI on the build agent
npm install -g apidog-cli

# Run the API test suite and emit a JUnit report for TeamCity
apidog run \
 --access-token "%env.APIDOG_ACCESS_TOKEN%" \
 -e "%env.APIDOG_ENV_ID%" \
 -r cli,junit \
 --out-dir reports

C'est la même commande que vous avez prouvée localement, avec deux modifications pour la CI. Premièrement, set -e fait avorter le script en cas d'erreur. Deuxièmement, les secrets sont référencés en tant que paramètres TeamCity (%env.APIDOG_ACCESS_TOKEN%) au lieu d'être codés en dur ; vous les définirez ensuite.

Si votre agent de build n'a pas encore Node.js, installez-le plus tôt dans la chaîne ou utilisez une image d'agent qui l'inclut. Les images Docker officielles des agents TeamCity et la plupart des pools d'agents cloud sont livrées avec Node.js disponible. Vous pouvez également exécuter l'étape entière dans un conteneur Node en configurant l'étape pour qu'elle s'exécute dans une image Docker comme node:20.

Un détail important à prendre en compte : la CLI doit s'exécuter après que votre API soit déployée et accessible. Si TeamCity teste un service qu'il vient de déployer en staging, faites en sorte que la build de test dépende de la build de déploiement en utilisant une dépendance d'instantané ou une chaîne de build. Cela garantit que les tests ciblent toujours la version de l'API produite par ce commit, jamais la précédente.

Étape 5 : Stockez les secrets en tant que paramètres TeamCity

Votre jeton d'accès est un identifiant. Il n'a pas sa place dans le script de build, dans votre dépôt ou dans le journal de build. TeamCity dispose d'un endroit privilégié pour cela.

1. Dans votre configuration de build (ou le projet parent, pour partager entre les configurations), ouvrez Paramètres.
2. Ajoutez un nouveau paramètre nommé env.APIDOG_ACCESS_TOKEN.
3. Définissez sa spécification sur Mot de passe. Cela masque la valeur dans l'interface utilisateur et la supprime des journaux de build.
4. Collez votre jeton d'accès Apidog comme valeur.
5. Ajoutez env.APIDOG_ENV_ID de la même manière avec votre ID d'environnement (celui-ci n'est pas secret, mais le conserver comme paramètre vous permet de changer d'environnement sans modifier le script).

Définir ces éléments au niveau du projet plutôt qu'au niveau de la configuration de build signifie que chaque build de test d'API de ce projet les hérite. Faites pivoter le jeton une fois, et chaque pipeline récupérera la nouvelle valeur.

Un paramètre de mot de passe fait la différence entre un jeton qui réside en toute sécurité dans TeamCity et un qui s'échappe dans un fichier journal que toute l'équipe peut lire. Traitez-le comme vous traiteriez un mot de passe de base de données.

Étape 6 : Affichez les résultats des tests dans l'onglet Tests de TeamCity

Une build qui passe au rouge vous indique que quelque chose a échoué. Une build qui montre quel test a échoué vous indique où chercher. C'est ce que le rapport JUnit vous offre.

Le rapporteur -r junit écrit un fichier XML au format JUnit, le format standard des résultats de tests CI que TeamCity lit nativement. Vous indiquez à TeamCity ce fichier avec une fonctionnalité de build de Traitement de rapport XML.

1. Ouvrez les fonctionnalités de build dans votre configuration de build.
2. Ajoutez le traitement de rapport XML.
3. Définissez le type de rapport sur Ant JUnit.
4. Définissez le chemin de surveillance pour qu'il corresponde à votre sortie, par exemple reports/*.xml.

Exécutez une build. Ouvrez-la et cliquez sur l'onglet Tests. Vous verrez chaque scénario et assertion comme un test individuel avec un statut de réussite/échec et un temps d'exécution. Lorsqu'un test échoue, TeamCity affiche le message d'échec en ligne, le lie au commit qui l'a introduit et le suit à travers les futures builds. Si le même test échoue deux fois de suite, TeamCity peut le signaler comme un nouvel échec plutôt que comme un échec instable.

C'est la récompense d'avoir choisi la sortie JUnit plus tôt. Sans cela, un échec est une build rouge et un mur de texte de console. Avec cela, vous obtenez un historique de tests structuré et consultable qui transforme « la build de l'API est cassée » en « l'assertion du total du panier a commencé à échouer dans le commit a3f9c2 ».

Étape 7 : Faites échouer la build et bloquez la fusion

Le but de tout cela est d'empêcher que du mauvais code ne soit fusionné. Deux choses y contribuent.

Premièrement, le code de sortie. Parce que la CLI Apidog se termine avec un code non nul en cas d'échec d'une assertion et que votre script utilise set -e, un test échoué fait échouer l'étape de build, ce qui fait échouer la build. Vous n'avez rien de plus à configurer ; un test API rouge est une build rouge par défaut.

Deuxièmement, la porte de fusion. Si votre équipe travaille avec des pull requests ou des merge requests, configurez votre hébergeur Git (GitHub, GitLab, Bitbucket) pour qu'il exige que la vérification TeamCity réussisse avant la fusion. TeamCity signale l'état de sa build au commit via une fonctionnalité de build Commit Status Publisher :

1. Ajoutez la fonctionnalité de build Commit Status Publisher.
2. Sélectionnez votre fournisseur d'hébergement VCS.
3. Ajoutez un jeton d'accès pour que TeamCity puisse publier les statuts.

Maintenant, un contributeur ouvre une PR, TeamCity exécute la suite d'API sur sa branche, et le bouton de fusion reste désactivé tant que la suite n'est pas au vert. Le scénario de champ renommé du début de ce guide est détecté ici, sur la branche, avant même qu'il n'atteigne `main`.

Un pipeline complet réaliste

En assemblant les pièces, une configuration de build fonctionnelle pour un pipeline de tests d'API ressemble à ceci :

• Racine VCS pointant vers votre dépôt, avec un déclencheur VCS sur la branche principale et les branches de PR.
• Étape de build 1 : déployer le service vers un environnement de staging (ou le démarrer dans un conteneur Docker sur l'agent).
• Étape de build 2 : la commande CLI Apidog de l'étape 4, exécutant votre suite contre cet environnement de staging.
• Fonctionnalités de build : Traitement de rapport XML lisant reports/*.xml.
• Fonctionnalités de build : Commit Status Publisher rapportant à votre hôte Git.
• Paramètres : env.APIDOG_ACCESS_TOKEN (mot de passe) et env.APIDOG_ENV_ID.

Pour les équipes qui maintiennent l'intégralité de leur configuration CI sous contrôle de version, TeamCity prend en charge la définition de tout cela dans un DSL Kotlin (.teamcity/settings.kts) commité dans le dépôt, au lieu de cliquer dans l'interface utilisateur. L'étape de build est la même commande apidog run dans les deux cas ; le DSL décrit simplement la configuration comme du code afin qu'elle soit révisée et versionnée aux côtés de tout le reste.

Vous pouvez exécuter la suite au-delà de chaque push. Ajoutez un Déclencheur planifié pour exécuter la suite de régression complète chaque nuit contre l'environnement de staging, afin de détecter les dérives qui se produisent entre les commits ; une dépendance tierce qui a changé, une base de données qui s'est retrouvée dans un état étrange. Les exécutions nocturnes d'API sont une assurance bon marché et elles empêchent le premier commit du matin d'hériter de l'environnement cassé de la veille.

Comment cela se compare aux autres plateformes CI

Le modèle ici est portable. La commande qui exécute vos tests (apidog run avec un jeton d'accès et un rapporteur JUnit) est identique quel que soit le serveur CI qui l'invoque. Seul l'habillage change :

• Dans GitHub Actions, vous mettriez la même commande dans une étape YAML de workflow. Nous couvrons cela dans Comment automatiser les tests d'API dans GitHub Actions.
• Dans Jenkins, cela se trouve dans une étape de Jenkinsfile. Voir Comment intégrer les tests automatisés Apidog avec Jenkins pour la CI/CD.
• La stratégie plus large sur n'importe quelle plateforme se trouve dans Comment automatiser les tests d'API en CI/CD.

Si vous choisissez encore un serveur CI, notre comparaison des meilleurs outils CI/CD explique où TeamCity se situe par rapport aux alternatives. Les forces de TeamCity sont ses chaînes de build, son historique de tests granulaire et le DSL Kotlin ; c'est un excellent choix pour les équipes déjà dans l'écosystème JetBrains ou exécutant des pipelines multi-étapes complexes.

Problèmes courants et comment les résoudre

La build ne trouve pas la commande apidog. Node.js n'est pas installé sur l'agent, ou le répertoire bin global de npm n'est pas dans le PATH de l'agent. Ajoutez une étape d'installation de Node plus tôt dans la chaîne, ou exécutez l'étape dans une image Docker node:20.

Les tests passent localement mais échouent en CI avec des erreurs de connexion. L'agent de build ne peut pas atteindre votre API. Une URL de staging qui se résout sur le VPN de votre ordinateur portable peut être inaccessible depuis un agent cloud. Confirmez que l'environnement que vous sélectionnez avec -e pointe vers un hôte que l'agent peut réellement atteindre, et que toutes les règles d'accès réseau ou de pare-feu requises couvrent l'agent.

L'authentification échoue uniquement en CI. Vérifiez que le paramètre de mot de passe est orthographié exactement comme le script le référence et que le jeton n'a pas expiré. Une erreur courante est de définir APIDOG_ACCESS_TOKEN alors que le script lit %env.APIDOG_ACCESS_TOKEN% ; le préfixe env. est important.

Les tests sont instables ; ils passent et échouent sur le même code. Généralement un problème de timing ou d'ordre des données. Utilisez les assertions de temps de réponse d'Apidog pour détecter les points de terminaison lents, et faites en sorte que chaque scénario configure et nettoie ses propres données afin que les exécutions ne dépendent pas des restes des autres. La fonctionnalité de mise en sourdine et d'investigation de TeamCity vous permet de mettre en quarantaine un test instable afin qu'il ne bloque plus tout le monde pendant que vous corrigez la cause première.

L'onglet Tests est vide même si la build a été exécutée. Le chemin de traitement du rapport XML ne correspond pas à l'endroit où la CLI a écrit le rapport. Confirmez que --out-dir dans la commande et le chemin de surveillance dans la fonctionnalité de build pointent vers le même endroit.

FAQ

Dois-je écrire du code pour exécuter des tests d'API dans TeamCity ? Non. Vous concevez les tests visuellement dans Apidog avec des assertions, et le seul « code » dans TeamCity est la commande apidog run d'une seule ligne dans une étape de build de type Ligne de commande. C'est la principale différence avec une approche axée sur le code comme REST Assured, où chaque point de terminaison nécessite un code de requête et d'assertion écrit à la main.

Puis-je exécuter les tests sur différents environnements ? Oui. Définissez chaque environnement (staging, pré-production, production-lecture seule) dans Apidog, puis changez celui qui s'exécute en CI en modifiant le paramètre -e de l'ID d'environnement. Les mêmes tests s'exécutent sur n'importe quel environnement en pointant vers une URL de base différente.

Comment puis-je sécuriser mon jeton d'accès dans TeamCity ? Stockez-le en tant que paramètre TeamCity avec la spécification Mot de passe. Cela le masque dans l'interface utilisateur et le supprime des journaux de build. Ne le codez jamais en dur dans le script de build ou ne le commitez jamais dans votre dépôt. Définissez-le au niveau du projet afin de pouvoir le faire pivoter une seule fois pour tous les pipelines.

Un test d'API échoué bloquera-t-il réellement une fusion ? Oui, avec deux éléments en place. La CLI Apidog se termine avec un code non nul en cas d'échec d'une assertion, ce qui fait échouer la build TeamCity. Ajoutez la fonctionnalité de build Commit Status Publisher et exigez la vérification dans les règles de protection de branche de votre hôte Git, et le bouton de fusion restera désactivé tant que la suite ne passera pas.

Quelle est la différence entre exécuter des tests en ligne ou à partir d'un fichier exporté ? L'exécution en ligne par ID de projet et jeton d'accès signifie que vos tests dans Apidog sont la source unique de vérité ; tout ce que l'équipe modifie est ce qui s'exécute en CI. L'exécution à partir d'un fichier exporté lie les tests à une version commitée dans votre dépôt. L'approche en ligne est plus simple à synchroniser ; l'approche exportée vous donne des tests qui voyagent avec le code. La plupart des équipes commencent en ligne.

Puis-je exécuter la suite de régression complète selon un calendrier au lieu de chaque push ? Oui. Ajoutez un Déclencheur planifié à la configuration de build pour l'exécuter chaque nuit (ou chaque heure) contre l'environnement de staging. De nombreuses équipes exécutent une suite de tests rapide à chaque push et la suite de régression complète selon un calendrier nocturne, afin que les retours rapides et la couverture approfondie ne se disputent pas les mêmes minutes.

En résumé

Un pipeline TeamCity qui exécute vos tests d'API à chaque commit change l'économie d'un point de terminaison défectueux. Au lieu qu'un client trouve le bug, la build le trouve ; sur la branche, avant la fusion, avec l'assertion exacte qui a échoué et le commit qui l'a causée, tout cela étant présenté dans l'onglet Tests.

La configuration se résume à trois éléments clés : des tests avec de vraies assertions que vous construisez dans Apidog, une seule commande apidog run qui les exécute sans interface graphique et se termine avec un code non nul en cas d'échec, et une configuration de build TeamCity qui exécute cette commande, analyse les résultats JUnit et signale l'état à votre hôte Git. Une fois en place, vous maintenez la couverture en ajoutant des scénarios dans Apidog, sans toucher au code du pipeline.

Téléchargez Apidog pour concevoir votre première suite de tests, prouvez la commande CLI localement, puis intégrez-la dans TeamCity. À partir de ce moment, votre API est testée de la même manière à chaque commit, que quelqu'un se souvienne de l'exécuter ou non.