Trae est une boucle. Son agent Builder lit votre référentiel, modifie des fichiers, exécute des commandes dans le terminal et lit la sortie pour décider de la prochaine étape. Alors pourquoi vos tests API ne sont-ils pas dans cette boucle ? Ils se trouvent dans Apidog derrière une interface graphique et ne s'exécutent que lorsque quelqu'un se souvient de cliquer. Votre agent ne les touche jamais.
La solution est un seul bloc de configuration. L'interface de ligne de commande (CLI) d'Apidog est un paquet npm, apidog-cli, qui exécute les scénarios de test que vous avez construits dans Apidog directement depuis un terminal. Une fois que la CLI est installée et que Trae sait qu'elle existe, le Builder exécute un scénario Apidog de la même manière qu'il exécute vos tests unitaires : lance la commande, lit le code de sortie, corrige le code s'il est rouge.
Si vous n'avez pas encore installé la CLI, faites-le d'abord. Comment installer la CLI Apidog avec un agent de codage IA détaille l'installation npm, l'authentification et la première exécution, l'agent se chargeant de la saisie. Cet article suppose que apidog --version affiche un nombre et que votre compte Apidog est authentifié.
De quel Trae il s'agit
Trae est l'IDE IA de ByteDance, construit sur VS Code, avec un mode agent appelé Builder qui modifie des fichiers et exécute des commandes de terminal de manière autonome. Vous pouvez lire les détails du produit sur le site officiel de Trae. Cet article concerne l'IDE de bureau, et non le projet de recherche autonome trae-agent sur GitHub. Si vous ouvrez Trae, voyez un panneau de discussion à côté de votre éditeur et pouvez passer l'agent en mode Builder, vous êtes au bon endroit.
La distinction est importante car Trae a sa propre façon d'apprendre les règles de projet, et ce mécanisme transforme un "exécuter mes tests" ponctuel en quelque chose que le Builder recherche de lui-même. Ce mécanisme est un fichier de règles de projet. Si vous souhaitez d'abord la version indépendante de l'outil de ce workflow, le guide complet de la CLI Apidog couvre la CLI seule.
Étape 1 : Ajouter le fichier de règles de projet
Trae lit les fichiers de règles avant que le Builder ne commence à travailler. Le fichier de niveau projet se trouve à l'emplacement .trae/rules/project_rules.md à la racine de votre référentiel, conformément à la documentation des règles de Trae. L'Agent charge ces règles lors de l'initialisation et s'y réfère lorsqu'il génère et modifie du code. Il existe également un fichier user_rules.md de niveau utilisateur qui s'applique à tous vos projets ; pour ce workflow, un fichier de projet à la racine du dépôt est suffisant.
Créez .trae/rules/project_rules.md et ajoutez un court bloc qui nomme la CLI, la commande exacte du scénario et les règles qui maintiennent l'honnêteté du Builder :
## Tests API avec la CLI Apidog
Lorsque vous modifiez du code qui touche un point de terminaison API, vérifiez-le
en exécutant le scénario de test Apidog, et pas seulement les tests unitaires.
Commande :
apidog run -t <scenario_id> -e <env_id> -r cli
Règles :
- `apidog run` sort avec le code 0 lorsque toutes les assertions passent et non-zéro en cas d'échec.
Traitez un code de sortie non-zéro comme un test échoué, même si le résumé semble correct.
- Cette machine est déjà authentifiée via `apidog login`. N'ajoutez jamais de
flag --access-token et ne mettez jamais de jeton dans ce fichier.
- Si un flag est inconnu, exécutez `apidog run --help` et utilisez le flag exact à partir de là.
C'est pourquoi vous écrivez la CLI dans project_rules.md au lieu de la mentionner dans le chat. Un ID de scénario tapé dans le panneau de discussion disparaît lorsque la session se termine. Un ID dans .trae/rules/project_rules.md est là pour chaque membre de l'équipe et chaque exécution du Builder à partir de maintenant. Trae lit également les dossiers .trae/rules/ dans les sous-répertoires, de sorte qu'un monorepo peut conserver des règles par service à côté de chaque service.
Étape 2 : Obtenir la commande depuis Apidog
Vous n'avez pas à deviner la commande. Ouvrez le scénario de test dans Apidog, allez dans l'onglet CI/CD et copiez la ligne apidog run générée. Elle contient déjà l'ID de scénario réel après -t et l'ID d'environnement après -e, vous collez donc une commande qu'Apidog sait être valide plutôt que d'inventer des ID à la main.
Insérez ces ID exacts dans le bloc de .trae/rules/project_rules.md, en remplaçant les espaces réservés <scenario_id> et <env_id>. Pour l'ensemble complet des flags et leur fonction, consultez la référence de la commande apidog run.
Étape 3 : Demander au Builder d'exécuter le test
Une fois le bloc en place, passez l'agent de Trae en mode Builder et démarrez-le dans votre dépôt. Le Builder charge project_rules.md lors de son initialisation, il sait donc déjà que la CLI est présente. Effectuez une modification qui touche votre API, ou demandez-lui simplement d'exécuter la vérification :
Exécutez le scénario de test Apidog et indiquez-moi le code de sortie.
Le Builder émet la commande apidog run à partir de votre fichier de règles. Le modèle d'approbation de Trae est important ici : lorsque l'agent veut exécuter une commande shell, il recommande la commande et affiche un bouton Exécuter, et la commande ne s'exécute dans le terminal de Trae qu'après votre clic. Une fois exécutée, le Builder lit et analyse automatiquement la sortie. Vous approuvez donc le apidog run une seule fois, et l'agent prend le résultat à partir de là.
Le rapporteur -r cli imprime un résultat pas à pas et un résumé directement dans le terminal, où le Builder lit chaque requête et assertion au fur et à mesure. Vous voulez voir l'exécution se dérouler et le Builder vous rapporter à la fois le résumé et le code de sortie.
Étape 4 : Lire le rapport dans Trae
Lorsqu'une exécution devient rouge, le rapport contient la réponse. Avec -r cli, le Builder obtient une ventilation lisible dans le terminal de Trae : chaque requête, chaque assertion et celle qui a échoué avec la valeur attendue par rapport à la valeur réelle. L'assertion échouée nomme le champ exact ou le code d'état, ce qui est généralement suffisant pour que le Builder trouve la correction.
Pour un rapport que vous pouvez ouvrir dans un navigateur ou remettre à un coéquipier, ajoutez le rapporteur HTML :
apidog run -t <scenario_id> -e <env_id> -r cli,html
Le rapporteur html écrit un fichier autonome dans ./apidog-reports. Gardez cli dans la liste afin que le Builder obtienne toujours la sortie en ligne qu'il lit pour décider de sa prochaine étape. Pour tous les rapporteurs, y compris les formats JSON et JUnit que les tableaux de bord CI analysent, consultez le guide des rapports de test de la CLI Apidog.
Trae teste dans sa propre boucle
Le point crucial est ce qui se passe lorsque vous arrêtez de demander et que le Builder exécute le scénario de lui-même parce que project_rules.md lui a dit de le faire.
Imaginez le Builder modifiant un gestionnaire qui construit une réponse de paiement. Sa boucle change : il modifie le code, puis, au lieu de déclarer victoire, exécute votre scénario Apidog sur l'environnement de staging, lit le code de sortie et agit en conséquence. Vert, il passe à autre chose. Rouge, il ouvre le rapport, lit quelle assertion a échoué (le code d'état, le champ manquant, la mauvaise valeur), essaie une correction et relance. Le test API devient une partie de la même boucle d'édition-test-correction par laquelle le Builder exécute déjà vos tests unitaires. Vous avez écrit une instruction et le Builder a intégré la commande dans son fonctionnement actuel.
C'est le modèle déléguer-puis-vérifier qui rend tout workflow d'agent sûr. Le Builder exécute la commande et lit le résultat ; vous continuez à créer des scénarios visuellement dans Apidog et à vérifier que l'agent lit les codes de sortie honnêtement. Pour le modèle plus large, consultez comment utiliser les agents IA pour les tests d'API et le harnais de test Apidog AI.
Vérifier que Trae exécute bien la CLI
Les agents signalent des succès qu'ils n'ont pas mérités, et le Builder ne fait pas exception. Trois vérifications, par ordre de fréquence de détection des problèmes.
Premièrement, confirmez que la commande a été exécutée. Trae affiche les commandes exécutées par le Builder et leur sortie dans le terminal. Recherchez la ligne littérale apidog run et un résultat en dessous. Si le Builder dit qu'il a exécuté les tests mais que vous ne voyez pas la commande, il a résumé quelque chose qu'il n'a jamais fait. Demandez-lui de réexécuter et d'afficher la sortie brute.
Deuxièmement, confirmez le code de sortie :
Quel était le code de sortie de cette commande apidog run ?
apidog run sort avec 0 lorsque toutes les assertions passent et non-zéro en cas d'échec. Ce comportement unique permet au Builder, ou à un pipeline, de traiter l'exécution comme un portail propre. Lorsque le texte du Builder dit "les tests ont réussi" mais que le code de sortie est non-zéro, c'est le code de sortie qui a raison.
Troisièmement, confirmez qu'il a utilisé le scénario réel. Si une exécution échoue avec "scénario non trouvé", le Builder a peut-être inventé ou mal mémorisé un ID. Revérifiez les valeurs -t et -e par rapport à project_rules.md et la commande qu'Apidog a générée dans l'onglet CI/CD. Les ID dans votre fichier de règles sont la vérité.
Facultatif : connecter le serveur Apidog MCP
L'exécution de apidog run à partir de project_rules.md couvre la plupart de vos besoins. La connexion d'un serveur MCP va un peu plus loin. Les agents Trae agissent comme des clients MCP, de sorte que le Builder peut appeler les outils qu'un serveur MCP expose.
Pour en ajouter un, ouvrez les paramètres de Trae, allez dans l'onglet MCP, et soit choisissez un serveur sur le marché, soit choisissez Ajouter manuellement et collez un bloc JSON avec la command, les args et l'env du serveur, conformément au guide de Trae pour l'ajout de serveurs MCP. Le serveur Apidog MCP expose vos spécifications API via MCP, de sorte que le Builder peut lire votre schéma pendant qu'il écrit du code, et non après coup. La division du travail est claire : la CLI exécute les tests, et MCP alimente l'agent avec la spécification.
Quand Trae se trompe
Quelques échecs apparaissent souvent lors de la configuration.
Il ignore le fichier de règles. Si le Builder exécute une commande générique ou aucune, le fichier peut ne pas se charger. Confirmez qu'il se trouve à .trae/rules/project_rules.md à la racine de votre référentiel et que le dossier est nommé rules, et non rule. Redémarrer la session force une nouvelle lecture des règles.
Il passe un jeton d'accès quand même. Si le Builder tente d'ajouter --access-token, il devine à partir d'exemples publics. Le bloc lui dit déjà de ne pas le faire, puisque la machine est authentifiée via apidog login. Renforcez cette ligne, et ne mettez jamais un vrai jeton dans project_rules.md. Pour savoir comment la CLI gère les informations d'identification en utilisation interactive et en CI, consultez l'authentification CLI Apidog.
Il invente un flag. Une erreur "option inconnue" signifie que le Builder a deviné un flag que votre version n'a pas. Dites-lui d'exécuter apidog run --help et de copier le flag exact à partir de là, ce qui est toujours correct pour votre version installée.
Il signale une réussite sur une exécution échouée. C'est le plus coûteux, et la raison pour laquelle la règle du code de sortie est dans votre project_rules.md et votre étape de vérification. Lorsque le résumé et le code de sortie ne concordent pas, le code de sortie l'emporte.
D'un agent quotidien à une boucle testée
Voilà la configuration. Installez apidog-cli une fois en suivant le guide d'installation, ajoutez un court bloc Apidog à .trae/rules/project_rules.md, et le Builder saura comment exécuter vos tests API et lire le résultat dans la même boucle qu'il utilise déjà pour modifier le code. Un point de terminaison cassé est détecté pendant que le Builder travaille encore sur la modification, et non après sa mise en production.
Un test derrière une interface graphique s'exécute lorsqu'un humain clique ; une commande d'une ligne s'exécute chaque fois que le Builder le décide. Vous continuez à construire des scénarios visuellement dans Apidog, et votre agent les exécute là où vous ne regardez pas. Téléchargez Apidog, construisez un scénario, insérez sa commande apidog run dans .trae/rules/project_rules.md, et regardez le Builder la prendre en compte lors du prochain changement. Lorsque vous êtes prêt à exécuter le même scénario sans agent présent, Apidog CLI dans GitHub Actions couvre les secrets, les rapporteurs et le contrôle du code de sortie pour la CI.