Antigravity est une boucle. Son agent modifie des fichiers, exécute des commandes de terminal, lit la sortie et décide de la prochaine étape. Alors, pourquoi vos tests d'API ne sont-ils pas dans cette boucle ? Ils restent dans Apidog, derrière une interface graphique, et ne s'exécutent que lorsque quelqu'un pense à cliquer. L'agent ne les touche jamais.
La solution est 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 la CLI installée et Antigravity informée de son existence, l'agent exécute un scénario Apidog de la même manière qu'il exécute vos tests unitaires : il lance la commande, lit le code de sortie et corrige le code s'il est en 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, 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 Antigravity il s'agit
Antigravity est la plateforme de développement agentique de Google, basée sur Gemini 3, lancée fin 2025. Elle exécute l'agent via un Gestionnaire d'Agents qui planifie le travail, modifie les fichiers de votre dépôt et exécute des commandes shell dans son propre terminal et navigateur. L'agent est la surface principale et il fonctionne directement sur votre machine locale. Si vous avez ouvert Antigravity, lancé une tâche et regardé l'agent exécuter des commandes et rendre compte, vous êtes au bon endroit. Pour une présentation plus large, consultez ce qu'est Google Antigravity et comment l'utiliser.
La distinction est importante car Antigravity a sa propre manière d'apprendre les règles du projet, et ce mécanisme transforme un simple « exécuter mes tests » en quelque chose que l'agent réalise de lui-même.
Étape 1 : Fournir un fichier de règles à Antigravity
Antigravity reconnaît un répertoire spécial .agents/ à la racine de votre espace de travail. Le codelab de Google sur la création de pipelines de développement autonomes dans Antigravity montre que l'agent récupère nativement les fichiers que vous y placez, et les règles de l'espace de travail se trouvent dans .agents/rules/. Placez les règles de votre projet dans un fichier tel que .agents/rules/apidog.md. Antigravity lit également un fichier AGENTS.md simple à la racine de l'espace de travail comme base inter-outils, le même fichier que Codex lit pour la CLI Apidog ; si vous en avez déjà un, ajoutez-y le bloc Apidog au lieu d'en maintenir deux.
Insérez un court bloc Apidog dans ce fichier de règles. Quelque chose comme ceci :
## Tests d'API avec la CLI Apidog
- Pour tester l'API, exécutez le scénario Apidog, ne cliquez pas sur l'interface graphique.
- Command: apidog run -t <scenario_id> -e <env_id> -r cli
- Le code de sortie 0 signifie que chaque assertion a été validée. Non-nul signifie un échec ; ouvrez le rapport et corrigez le code.
- La machine est déjà authentifiée via `apidog login`. N'ajoutez jamais d'indicateur --access-token et ne placez jamais de jeton dans ce fichier.
C'est pourquoi vous inscrivez la CLI dans le fichier de règles au lieu de la mentionner dans le chat. Antigravity ne se souvient pas de ce que vous lui apprenez entre les sessions ; fermez la fenêtre, rouvrez-la, et le coaching a disparu. Un ID de scénario tapé dans le chat disparaît à la fin de la session. Un ID écrit dans votre fichier de règles est là pour chaque coéquipier et chaque exécution d'Antigravity à partir de maintenant.
Étape 2 : Obtenir la commande depuis Apidog
Vous n'avez pas à deviner les identifiants de scénario et d'environnement. Ouvrez le scénario de test dans Apidog, allez dans son onglet CI/CD et copiez la commande générée. Elle ressemble à ceci :
apidog run -t 123456 -e 789012 -r cli
L'indicateur -t est l'ID du scénario de test, -e est l'ID de l'environnement, et -r cli sélectionne le rapporteur qui affiche les résultats en ligne. Collez ces ID réels dans votre bloc .agents/rules/apidog.md afin que l'agent exécute la commande exacte que Apidog vous a fournie. Pour chaque indicateur, consultez la référence de la commande apidog run.
Étape 3 : Demander à l'agent d'exécuter le test
Une fois le bloc en place, démarrez une tâche dans Antigravity. L'agent charge vos règles dès le début, il sait donc déjà que la CLI est présente. Apportez 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 donnez-moi le code de sortie.
L'agent exécute la commande apidog run de votre fichier de règles dans son propre terminal. Le fait qu'il s'exécute sans demander dépend de vos paramètres d'autorisation. Le préréglage de sécurité d'Antigravity détermine si les commandes de terminal et les accès aux fichiers sont examinés par vous avant que l'agent n'agisse, comme décrit dans le codelab de Google pour démarrer avec Antigravity. Si le préréglage demande une révision, approuvez la commande apidog run lorsqu'elle vous y invite ; un scénario de test en lecture seule contre l'environnement de staging est exactement le type de commande sûre, au sein de l'espace de travail, qui peut être approuvée. Si vous avez configuré l'agent pour qu'il procède seul, il exécute la commande et rend compte sans s'arrêter.
Vous voulez voir l'exécution et l'agent rapporter à la fois le résumé et le code de sortie, pas une paraphrase.
Étape 4 : Lire le rapport dans Antigravity
Lorsqu'une exécution devient rouge, le rapport contient la réponse. Avec -r cli, l'agent obtient une ventilation lisible dans son terminal : chaque requête, chaque assertion, et celle qui a échoué avec la valeur attendue versus la valeur réelle. L'assertion échouée nomme le champ ou le code de statut exact, ce qui est généralement suffisant pour que l'agent 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 123456 -e 789012 -r cli,html
Le rapporteur html écrit un fichier autonome dans ./apidog-reports. Gardez cli dans la liste afin que l'agent reçoive toujours la sortie en ligne qu'il lit pour décider de sa prochaine étape. Pour l'ensemble complet des rapporteurs, y compris le format 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.
Tests Antigravity au sein de sa propre boucle
L'intérêt est ce qui se passe lorsque vous arrêtez de demander et que l'agent exécute le scénario de lui-même parce que le fichier de règles le lui a indiqué.
Imaginez l'agent modifiant un gestionnaire qui construit une réponse de commande. 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. En vert, il passe à autre chose. En 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 fait partie de la même boucle d'édition-test-correction que celle que l'agent utilise déjà pour vos tests unitaires. Vous avez écrit une instruction et l'agent a intégré la commande à son fonctionnement existant.
C'est le modèle « déléguer puis vérifier » qui sécurise tout flux de travail d'agent. Antigravity exécute la commande et lit le résultat ; vous continuez à créer des scénarios visuellement dans Apidog et vérifiez ponctuellement 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 Apidog.
Vérifier qu'Antigravity exécute réellement la CLI
Les agents signalent des succès qu'ils n'ont pas mérités, et Antigravity 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 bien été exécutée. Antigravity affiche les commandes qu'il a exécutées et leur sortie dans son terminal. Recherchez la ligne littérale apidog run ... et un résultat en dessous. Si l'agent 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 d'afficher la sortie brute.
Deuxièmement, confirmez le code de sortie, celui qui compte. Demandez directement :
Quel a été le code de sortie de cette commande apidog run ?
apidog run se termine avec 0 lorsque toutes les assertions sont validées et non-nul en cas d'échec. Ce comportement unique permet à l'agent, ou à un pipeline, de considérer l'exécution comme une porte d'entrée claire. Lorsque le discours de l'agent 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 », l'agent a peut-être inventé ou mal mémorisé un ID. Vérifiez à nouveau les valeurs -t et -e par rapport à votre fichier de règles et à la commande Apidog générée dans l'onglet CI/CD. Les ID de votre fichier de règles sont la vérité.
Facultatif : Connecter le serveur MCP Apidog
Exécuter apidog run depuis votre fichier de règles couvre la plupart de vos besoins. Pour aller plus loin, connectez un serveur MCP.
Antigravity prend en charge le protocole de contexte de modèle (MCP), et ses serveurs MCP sont configurés dans le fichier $HOME/.gemini/config/mcp_config.json, selon le codelab de Google pour démarrer. Vous ajoutez un serveur comme entrée dans l'objet mcpServers de ce fichier avec sa command, ses args et son env, puis vous actualisez le MCP dans les paramètres d'Antigravity. Le serveur MCP Apidog expose vos spécifications d'API via le MCP, afin que l'agent puisse lire votre schéma pendant qu'il écrit du code, et non pas seulement après coup. La CLI exécute les tests ; le MCP fournit la spécification à l'agent.
Quand Antigravity se trompe
Quelques échecs apparaissent souvent lors de la configuration.
Il ignore le fichier de règles. Si l'agent exécute une commande générique ou aucune, les règles peuvent ne pas se charger. Confirmez que le fichier est nommé correctement et se trouve là où Antigravity l'attend pour votre espace de travail, puis démarrez une nouvelle tâche pour qu'il relise les règles.
Il transmet quand même un jeton d'accès. Si l'agent essaie d'ajouter --access-token, c'est qu'il se base sur des exemples publics. Votre bloc de règles 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 le fichier de règles. Pour savoir comment fonctionne réellement l'authentification, consultez l'authentification CLI Apidog.
Il invente un indicateur. Une erreur « option inconnue » signifie que l'agent a deviné un indicateur que votre version ne possède pas. Dites-lui d'exécuter apidog run --help et de copier l'indicateur 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. Le plus coûteux, et la raison pour laquelle la règle du code de sortie se trouve dans votre fichier de règles et dans votre étape de vérification. Lorsque le résumé et le code de sortie sont en désaccord, 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 à votre fichier de règles Antigravity, et l'agent 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 défectueux est détecté pendant que l'agent 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 ligne s'exécute chaque fois qu'Antigravity le décide. Vous continuez à créer des scénarios visuellement dans Apidog, et votre agent les exécute là où vous ne regardez pas. Téléchargez Apidog, créez un scénario, insérez sa commande apidog run dans votre fichier de règles, et observez l'agent la prendre en compte lors de la prochaine modification. Lorsque vous êtes prêt à exécuter la même commande dans un pipeline sans agent, Apidog CLI dans GitHub Actions couvre les secrets, les rapporteurs et le filtrage par code de sortie.