Le mode agent de GitHub Copilot est une boucle : il modifie des fichiers, exécute des commandes de terminal, lit la sortie et décide quoi faire ensuite. Alors, pourquoi vos tests d'API ne sont-ils pas dans cette boucle ? Ils sont dans Apidog derrière une interface graphique, exécutés quand quelqu'un se souvient de cliquer. Copilot ne les touche jamais.
La solution est un seul fichier 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 créés dans Apidog directement depuis un terminal. Une fois la CLI installée et que Copilot sait qu'elle existe, le mode agent exécute un scénario Apidog de la même manière qu'il exécute vos tests unitaires : lancez la commande, lisez le code de sortie, corrigez 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 explique l'installation npm, la connexion et la première exécution, avec un agent qui tape. Cet article suppose que apidog --version affiche un nombre et que votre compte Apidog est authentifié.
De quel Copilot il s'agit
Copilot regroupe plusieurs produits, et leurs noms se recoupent de manière confuse. Cet article traite des interfaces qui peuvent exécuter des commandes shell.
Le principal est le **mode agent dans VS Code**. Vous ouvrez la vue Copilot Chat, basculez le menu déroulant du mode sur Agent, et il peut modifier plusieurs fichiers, exécuter des commandes de terminal et itérer jusqu'à ce que la tâche soit terminée. Lorsqu'il souhaite exécuter une commande, il vous la montre et demande confirmation avant l'exécution. Cette étape de confirmation est exactement là où apidog run s'intègre.
Deux interfaces connexes méritent d'être nommées afin que vous sachiez dans laquelle vous vous trouvez. L'**agent de codage Copilot** s'exécute de manière asynchrone dans GitHub Actions après que vous lui ayez attribué un problème ; il produit une pull request plutôt que de travailler dans votre éditeur. La **CLI Copilot** est un client de terminal distinct. Les deux peuvent exécuter des commandes, mais cet article cible le mode agent dans VS Code, car c'est là que vous travaillez pendant que vous codez et où la boucle édition-test-correction est la plus serrée. La configuration ci-dessous fonctionne également pour l'agent de codage, qui lit le même fichier d'instructions. Pour un aperçu plus large de ce qui a changé lorsque Copilot est devenu un agent, consultez le nouvel agent de codage de GitHub Copilot.
La distinction est importante car Copilot a sa propre façon d'apprendre les règles d'un projet, et ce mécanisme transforme un "exécuter mes tests" ponctuel en quelque chose que Copilot utilise de lui-même. Ce mécanisme est un fichier d'instructions personnalisé.
Étape 1 : Ajouter les règles Apidog au fichier d'instructions de Copilot
Copilot lit les instructions personnalisées du dépôt à partir d'un seul fichier : .github/copilot-instructions.md à la racine de votre dépôt. Le mode agent, Copilot Chat, la revue de code et l'agent de codage le chargent tous automatiquement, conformément aux documents GitHub sur les instructions personnalisées de dépôt. Considérez-le comme CLAUDE.md pour Claude Code ou AGENTS.md pour Codex : un fichier Markdown simple d'instructions de projet que Copilot intègre au contexte avant de commencer à travailler.
Créez le fichier et ajoutez un court bloc Apidog :
## API testing with the Apidog CLI
When you change an API endpoint, verify it with the Apidog CLI before
declaring the task done. Run:
apidog run -t 812345 -e 671234 -r cli
- `apidog run` exits 0 when every assertion passes, non-zero on any failure.
Treat a non-zero exit as a failing test, even if the summary text looks fine.
- The machine is already authenticated via `apidog login`. Do NOT add an
`--access-token` flag and never put a token in this file.
- If you hit an "unknown option" error, run `apidog run --help` and use the
real flags. Do not guess.
Remplacez les valeurs -t et -e par vos véritables ID de scénario et d'environnement de l'étape suivante.
Écrivez-le dans le fichier d'instructions plutôt que de le mentionner dans le chat, car un ID de scénario tapé dans le chat disparaît à la fin de la session. Un ID dans .github/copilot-instructions.md est là pour chaque membre de l'équipe, chaque session en mode agent et chaque pull request que l'agent de codage ouvrira désormais. Si vous souhaitez que la règle ne s'applique qu'à certains fichiers, GitHub prend également en charge les instructions spécifiques au chemin dans .github/instructions/NAME.instructions.md, mais un seul fichier à l'échelle du dépôt suffit ici.
Étape 2 : Obtenir la commande depuis Apidog
Vous n'avez pas à écrire la commande apidog run à la main. Apidog la génère pour vous.
Ouvrez le scénario de test dans Apidog, allez dans l'onglet **CI/CD** et copiez la commande. Elle est entièrement formée avec l'ID de scénario (-t), l'ID d'environnement (-e) corrects et un flag de rapporteur :
apidog run -t 812345 -e 671234 -r cli
Collez ces ID exacts dans le bloc de votre .github/copilot-instructions.md. Ces ID sont la source de vérité ; lorsque Copilot et votre fichier d'instructions sont en désaccord, l'onglet CI/CD l'emporte. Pour l'ensemble complet des flags et des rapporteurs, consultez la référence de la commande apidog run.
Étape 3 : Demander au mode agent d'exécuter le test
Ouvrez la vue Copilot Chat dans VS Code et basculez le menu déroulant du mode sur **Agent**. Parce que le mode agent charge .github/copilot-instructions.md au démarrage, il sait déjà que la CLI est présente. Apportez une modification qui affecte votre API, ou demandez-lui directement :
Run the Apidog API test scenario and tell me the result.
Copilot émet la commande apidog run à partir de votre fichier d'instructions. Le mode agent n'exécute pas les commandes de terminal en silence ; il vous montre la commande et vous demande de confirmer avant l'exécution, afin que vous voyiez exactement ce qui est sur le point de s'exécuter. Approuvez-la. Le rapporteur -r cli imprime ensuite un résultat étape par étape et un résumé directement dans le terminal intégré, où vous observez chaque requête et chaque assertion au fur et à mesure qu'elles se produisent.
Vous voulez voir deux choses : l'exécution du test, et Copilot qui vous rapporte le résumé et le code de sortie. Si vous approuvez la commande une fois, VS Code peut se souvenir de votre choix pour cette commande dans l'espace de travail, de sorte que les appels apidog run ultérieurs s'exécutent sans nouvelle invite. Un scénario de test en lecture seule contre l'environnement de staging est exactement le genre de commande sûre, dans l'espace de travail, qu'il est acceptable d'autoriser.
Étape 4 : Lire le rapport dans Copilot
Lorsqu'une exécution passe au rouge, le rapport contient la réponse. Avec -r cli, Copilot obtient une ventilation lisible dans le terminal : chaque requête, chaque assertion, et laquelle a échoué avec la valeur attendue par rapport à la valeur réelle. L'assertion défaillante nomme le champ exact ou le code de statut, ce qui est généralement suffisant pour que Copilot trouve la correction lors de sa prochaine itération.
Pour un rapport que vous pouvez ouvrir dans un navigateur ou remettre à un coéquipier, ajoutez le rapporteur HTML :
apidog run -t 812345 -e 671234 -r cli,html
Le rapporteur html écrit un fichier autonome dans ./apidog-reports. Gardez cli dans la liste pour que Copilot reçoive toujours la sortie en ligne qu'il lit pour décider de sa prochaine étape. Pour tous les formats de rapporteurs, y compris la sortie JUnit que les tableaux de bord CI analysent, consultez le guide complet de la CLI Apidog et comment lire les rapports de test de la CLI Apidog.
Copilot testant dans sa propre boucle
Le point est ce qui se passe lorsque vous arrêtez de demander et que Copilot exécute le scénario de lui-même parce que le fichier d'instructions le lui a dit.
Imaginez le mode agent 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 contre 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 de statut, le champ manquant, la mauvaise valeur), tente une correction et réexécute. Le test d'API devient partie intégrante de la même boucle d'édition-test-correction que Copilot utilise déjà pour vos tests unitaires. Vous avez écrit une seule instruction et Copilot a intégré la commande à son fonctionnement habituel.
C'est le modèle déléguer-puis-vérifier qui sécurise tout workflow d'agent. Copilot 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 honnêtement les codes de sortie. Pour le modèle plus large, consultez comment utiliser les agents IA pour les tests d'API et le harnais de test IA Apidog.
Vérifier que Copilot exécute réellement la CLI
Les agents signalent des succès qu'ils n'ont pas mérités, et Copilot 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. Le mode agent affiche les commandes qu'il a exécutées et leur sortie directement dans le terminal. Recherchez la ligne littérale apidog run ... et un résultat en dessous. Si Copilot 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 l'exécuter à nouveau et de montrer la sortie brute.
Deuxièmement, confirmez le code de sortie, celui qui compte :
What was the exit code of that apidog run command?
apidog run se termine avec 0 lorsque toutes les assertions passent et avec une valeur non nulle en cas d'échec. Ce comportement unique permet à Copilot, ou à un pipeline, de traiter l'exécution comme une porte d'entrée claire. Lorsque le texte de Copilot indique « tests réussis » mais que le code de sortie est non nul, le code de sortie a raison.
Troisièmement, confirmez qu'il a utilisé le scénario réel. Si une exécution échoue avec « scénario non trouvé », Copilot a peut-être inventé ou mal mémorisé un ID. Vérifiez à nouveau les -t et -e par rapport à votre fichier d'instructions et à la commande Apidog générée dans l'onglet CI/CD. Les ID d'Apidog sont la vérité.
Optionnel : connecter le serveur Apidog MCP
L'exécution de apidog run à partir de votre fichier d'instructions couvre la plupart de vos besoins. Pour aller plus loin, connectez le serveur Apidog MCP.
Le mode agent dans VS Code lit les serveurs MCP à partir d'un fichier .vscode/mcp.json dans la racine de votre dépôt, conformément aux documents GitHub sur l'extension de Copilot avec MCP. Le serveur Apidog MCP expose vos spécifications d'API via MCP, afin que Copilot puisse lire votre schéma pendant qu'il écrit du code, et non pas seulement après coup. La division du travail est claire : la CLI exécute les tests, et MCP fournit les spécifications à l'agent.
Si vous exécutez l'agent de codage Copilot dans GitHub Actions à la place, sa configuration MCP se trouve à un endroit différent. Vous l'ajoutez en JSON sous les paramètres du dépôt, dans la section Copilot sous Cloud agent, avec tous les secrets stockés comme des secrets d'Actions préfixés COPILOT_MCP_. Le fichier .vscode/mcp.json est destiné au mode agent dans votre éditeur.
Quand Copilot se trompe
Quelques erreurs apparaissent souvent lors de la configuration.
Il ignore le fichier d'instructions. Si Copilot exécute une commande générique ou aucune, le fichier peut ne pas se charger. Confirmez qu'il est nommé exactement .github/copilot-instructions.md, qu'il se trouve dans le répertoire .github à la racine de votre dépôt et que les instructions personnalisées sont activées dans vos paramètres VS Code. Un chemin incorrect signifie que Copilot ne le lit jamais.
Il transmet quand même un jeton d'accès. Si Copilot essaie d'ajouter --access-token, il devine à partir d'exemples publics. Le bloc lui dit déjà de ne pas le faire, car la machine est authentifiée via apidog login. Renforcez cette ligne, et ne mettez jamais de véritable jeton dans le fichier d'instructions. Pour le modèle d'authentification, consultez l'authentification de la CLI Apidog.
Il invente un flag. Une erreur « option inconnue » signifie que Copilot a deviné un flag que votre version ne possède 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 rapporte un succès sur une exécution échouée. C'est l'erreur la plus coûteuse, et la raison pour laquelle la règle du code de sortie se trouve à la fois dans votre fichier d'instructions et dans votre étape de vérification. Lorsque le résumé et le code de sortie ne correspondent pas, le code de sortie l'emporte.
D'un agent quotidien à une boucle testée
Voilà la configuration. Installez apidog-cli une seule fois en suivant le guide d'installation, ajoutez un court bloc Apidog au fichier .github/copilot-instructions.md de votre dépôt, et Copilot saura comment exécuter vos tests d'API et lire le résultat dans la même boucle qu'il utilise déjà pour éditer le code. Un endpoint cassé est détecté pendant que Copilot travaille encore sur la modification, et non après le déploiement.
Un test derrière une interface graphique s'exécute lorsqu'un humain clique ; une commande d'une seule ligne s'exécute chaque fois que Copilot 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 .github/copilot-instructions.md, et regardez Copilot l'adopter lors du prochain changement. Lorsque vous êtes prêt à exécuter la même commande dans un pipeline sans Copilot, la CLI Apidog dans GitHub Actions couvre les secrets, les rapporteurs et le filtrage par code de sortie.