Cline est une boucle : elle planifie un changement, édite des fichiers, exécute des commandes, lit la sortie et décide de la prochaine étape. Alors pourquoi vos tests d'API ne sont-ils pas dans cette boucle ? Ils sont dans Apidog, derrière une interface graphique, attendant que quelqu'un se souvienne de cliquer. Votre agent ne les touche jamais.
La solution tient en un seul bloc de configuration. L'interface de ligne de commande (CLI) d'Apidog est un package npm, `apidog-cli`, qui exécute les scénarios de test que vous avez créés dans Apidog directement depuis un terminal. Une fois que la CLI est installée et que Cline sait qu'elle existe, votre 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 en échec.
Si vous n'avez pas encore installé la CLI, faites-le en premier. Comment installer la CLI Apidog avec un agent de codage IA vous guide à travers l'installation npm, l'authentification et le premier lancement, avec Cline qui effectue la saisie. Cet article suppose que `apidog --version` affiche un numéro et que votre compte Apidog est authentifié.
De quelle Cline il s'agit
Cline est l'agent de codage autonome open-source qui fonctionne comme une extension VS Code (il existe aussi une version JetBrains et une CLI). Il lit votre dépôt, planifie en mode Plan, puis passe en mode Action pour éditer des fichiers et exécuter des commandes shell, demandant votre approbation en fonction de vos paramètres d'approbation automatique. Ce n'est pas un chatbot hébergé ; le modèle s'exécute sur votre base de code, sur votre machine. Si vous avez le panneau Cline ouvert dans VS Code et qu'il affiche des différences et des sorties de terminal pendant qu'il travaille, vous êtes au bon endroit. Comment utiliser Cline couvre les bases de son installation et du choix d'un modèle.
Cette distinction est importante car Cline a sa propre façon d'apprendre les règles d'un projet, et ce mécanisme transforme un « exécute mes tests » ponctuel en quelque chose que Cline utilise de manière autonome. Ce mécanisme est le répertoire `.clinerules/`.
Étape 1 : Ajoutez la règle à .clinerules, pas à un rappel de chat
Cline charge les règles de projet depuis un répertoire `.clinerules/` à la racine de votre espace de travail avant de commencer une tâche. Il lit chaque fichier `.md` et `.txt` à l'intérieur de ce dossier et les combine en l'ensemble d'instructions qu'il utilise pendant la session. Vous pouvez également utiliser un seul fichier `.clinerules` si vous préférez, mais le répertoire s'adapte mieux à mesure que vos règles se développent. Ceci est documenté dans la référence des règles Cline.
Créez un fichier tel que `.clinerules/apidog.md` à la racine de votre dépôt avec un court bloc comme celui-ci :
# Test API avec Apidog
- Pour tester l'API, exécutez la CLI Apidog, et non curl ou des scripts ad-hoc.
- Commande : apidog run -t <scenario_id> -e <env_id> -r cli
- L'ID du scénario et l'ID de l'environnement proviennent de l'onglet CI/CD d'Apidog. Utilisez ces valeurs exactes.
- Le code de sortie 0 signifie que toutes les assertions ont réussi. Non-zéro signifie un échec ; le code de sortie est la source de vérité, pas votre résumé.
- La machine est déjà authentifiée via `apidog login`. N'ajoutez jamais --access-token et ne mettez jamais de jeton dans ce fichier.
- Si un drapeau est inconnu, exécutez `apidog run --help` et utilisez le drapeau exact à partir de là.
C'est pourquoi vous écrivez la CLI dans `.clinerules/` au lieu de la mentionner dans le chat. Un ID de scénario tapé dans un message Cline disparaît à la fin de la tâche. Un ID dans `.clinerules/apidog.md` est là pour chaque coéquipier qui extrait le dépôt et pour chaque tâche Cline à partir de maintenant. Le fichier est versionné, donc la règle voyage avec le code.
Étape 2 : Obtenez la commande depuis Apidog
Vous avez besoin de la vraie commande `apidog run`, pas d'une commande devinée. Ouvrez le scénario de test dans Apidog, allez à son onglet CI/CD et copiez la commande générée. Elle ressemble à ceci :
apidog run -t 8291 -e 42 -r cli
La valeur `-t` est l'ID de votre scénario de test et `-e` est l'ID de l'environnement. Ce sont les valeurs exactes qui doivent figurer dans `.clinerules/apidog.md`. Collez-les dans le bloc de règles afin que Cline ait toujours les bons IDs. Pour l'ensemble complet des drapeaux, consultez la référence de la commande apidog run.
Étape 3 : Demandez à Cline d'exécuter le test
Avec la règle en place, lancez une tâche dans le panneau Cline. Cline charge `.clinerules/` au démarrage, il sait donc déjà que la CLI est là. Effectuez une modification qui affecte votre API, ou demandez-lui simplement d'exécuter la vérification :
Exécutez le scénario de test Apidog et dites-moi le résultat.
Cline planifie l'étape, puis passe en mode Action pour émettre la commande `apidog run` à partir de vos règles. La quantité de demandes dépend de vos paramètres d'approbation. Cline évalue chaque commande et la marque comme sûre ou nécessitant une approbation ; un scénario de test en lecture seule contre un environnement de staging est le type de commande qu'il considère comme sûr. Si vos paramètres d'approbation automatique permettent l'exécution de commandes sûres, `apidog run` s'exécute sans invite. Sinon, Cline met en pause et demande ; approuvez-la et activez l'approbation automatique pour les commandes sûres si vous voulez qu'il exécute les futurs scénarios de lui-même. Le rapporteur `-r cli` affiche un résultat étape par étape et un résumé directement dans le terminal, où vous observez chaque requête et assertion au fur et à mesure de leur exécution.
Étape 4 : Lisez le rapport dans Cline
Lorsqu'une exécution passe au rouge, le rapport contient la réponse. Avec `-r cli`, Cline obtient un rapport détaillé lisible dans le panneau de sortie du terminal : chaque requête, chaque assertion et celle qui a échoué, avec la valeur attendue par rapport à la valeur réelle. L'assertion défaillante nomme le champ exact ou le code d'état, ce qui est généralement suffisant pour que Cline trouve la correction lors de son prochain passage.
Pour un rapport que vous pouvez ouvrir dans un navigateur ou donner à un coéquipier, ajoutez le rapporteur HTML :
apidog run -t 8291 -e 42 -r cli,html
Le rapporteur `html` écrit un fichier autonome dans `./apidog-reports`. Gardez `cli` dans la liste afin que Cline obtienne toujours la sortie en ligne qu'il lit pour décider de sa prochaine étape. Pour chaque drapeau et rapporteur, y compris le format JUnit que les tableaux de bord CI analysent, consultez le guide complet de la CLI Apidog et le guide des rapports de test de la CLI Apidog.
Tests Cline dans sa propre boucle
Le bénéfice, c'est ce qui se passe lorsque vous arrêtez de demander et que Cline exécute le scénario de lui-même parce que `.clinerules/` lui a dit de le faire.
Imaginez Cline éditant un gestionnaire qui construit une réponse de paiement. Sa boucle change : il édite 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. Si c'est vert, il passe à l'étape suivante. Si c'est 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 une partie de la même boucle d'édition-test-correction que Cline utilise déjà pour vos tests unitaires. Vous avez écrit une seule instruction et Cline a intégré la commande à son fonctionnement habituel.
C'est le modèle de délégation puis de vérification qui sécurise tout flux de travail d'agent. Cline exécute la commande et lit le résultat ; vous continuez à créer visuellement des scénarios 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 IA d'Apidog.
Vérifiez que Cline exécute réellement la CLI
Les agents rapportent des succès qu'ils n'ont pas mérités, et Cline ne fait pas exception. Trois vérifications, par ordre de fréquence à laquelle elles détectent des problèmes.
Premièrement, confirmez que la commande a bien été exécutée. Cline affiche les commandes qu'il a exécutées et leur sortie en ligne dans la vue des tâches. Cherchez la ligne littérale `apidog run ...` et un résultat en dessous. Si Cline 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 :
Quel était le code de sortie de cette commande apidog run ?
`apidog run` se termine avec `0` lorsque toutes les assertions passent et avec un code non nul lorsque quelque chose échoue. Ce comportement unique permet à Cline, ou à un pipeline, de considérer l'exécution comme une étape claire. Lorsque le texte de Cline dit « 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 vrai scénario. Si une exécution échoue avec « scénario introuvable », Cline a peut-être inventé ou mal mémorisé un ID. Vérifiez à nouveau les valeurs `-t` et `-e` par rapport à `.clinerules/apidog.md` et la commande Apidog générée dans l'onglet CI/CD. Les IDs dans le fichier de règles sont la vérité.
Optionnel : Connecter le serveur MCP d'Apidog
Exécuter `apidog run` depuis `.clinerules/` couvre la plupart de vos besoins. Une autre voie va plus loin.
Cline offre un support de première classe pour le Protocole de Contexte de Modèle (MCP). Dans l'extension VS Code, cliquez sur l'icône Serveurs MCP dans le panneau Cline, ouvrez Configurer, et cliquez sur Configurer les Serveurs MCP pour ouvrir `cline_mcp_settings.json` ; ajoutez votre serveur sous l'objet `mcpServers`. Vous pouvez également parcourir le Marché MCP à l'intérieur de Cline pour installer des serveurs sans éditer de JSON manuellement, comme décrit dans la documentation MCP de Cline. Le serveur MCP Apidog expose vos spécifications d'API via MCP, afin que Cline puisse lire votre schéma pendant qu'il écrit du code, et non pas après coup seulement. La CLI exécute les tests ; MCP alimente l'agent avec la spécification.
Cline est une extension interactive, il n'y a donc pas de mode de test non interactif intégré comme le ferait un runner headless. Pour exécuter `apidog run` dans un pipeline sans que Cline ne soit présent, la CLI Apidog dans GitHub Actions couvre les secrets, les rapporteurs et le contrôle du code de sortie, et le guide de pipeline CI/CD de la CLI Apidog couvre la configuration plus large.
Quand Cline se trompe
Quelques échecs apparaissent souvent lors de la configuration.
Il ignore le fichier de règles. Si Cline exécute une commande générique ou aucune, la règle pourrait ne pas être chargée. Confirmez que le dossier est nommé exactement `.clinerules` et qu'il se trouve à la racine de votre espace de travail, et que le fichier à l'intérieur se termine par `.md` ou `.txt`. Lancer une nouvelle tâche force Cline à recharger les règles.
Il transmet quand même un jeton d'accès. Si Cline essaie d'ajouter `--access-token`, c'est qu'il devine à partir d'exemples publics. La règle 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 de vrai jeton dans `.clinerules/`. Pour savoir comment fonctionne réellement l'authentification, consultez le guide d'authentification de la CLI Apidog.
Il invente un drapeau. Une erreur « option inconnue » signifie que Cline a deviné un drapeau que votre version ne possède pas. Dites-lui d'exécuter `apidog run --help` et de copier le drapeau exact à partir de là, ce qui est toujours correct pour votre version installée.
Il signale un succès pour 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 `.clinerules/` 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 fois en suivant le guide d'installation, ajoutez une courte règle Apidog au répertoire `.clinerules/` de votre dépôt, et Cline saura comment exécuter vos tests d'API et lire le résultat à l'intérieur de la même boucle qu'il utilise déjà pour éditer le code. Un endpoint cassé est détecté pendant que Cline travaille encore sur la modification, et non après son déploiement.
Un test derrière une interface graphique s'exécute quand un humain clique ; une commande d'une seule ligne s'exécute chaque fois que Cline le décide. Vous continuez à construire visuellement des scénarios 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 `.clinerules/apidog.md`, et regardez Cline la prendre en compte lors du prochain changement.