Agent IA pour tester une API : méthode, vérifications et limites

Un agent IA peut vous aider à préparer des tests d’API, mais il ne sait pas à lui seul quelles règles métier sont correctes. Utilisez-le pour transformer un contrat existant en cas de test, puis vérifiez les requêtes, les assertions et les effets de bord. Le bon résultat n’est pas « beaucoup de tests générés » : c’est une suite lisible qui prouve des comportements importants.

Ce que vous allez apprendre

Ce guide montre comment partir d’un endpoint documenté, demander une proposition de tests limitée, vérifier chaque étape et traiter les erreurs fréquentes. La méthode convient à un débutant qui a déjà un projet exécutable et souhaite tester une API HTTP sans confier ses données ou ses règles métier à l’outil.

Prérequis

Vous avez besoin d’une route API dont le contrat est connu : méthode HTTP, chemin, données reçues, réponse attendue et erreurs importantes. Préparez aussi une commande de test existante et, si possible, un exemple de test voisin dans le dépôt. N’insérez jamais dans un prompt un token, un mot de passe, une URL interne ou des données de production. Remplacez-les par des variables fictives.

Avant d’utiliser l’agent, exécutez le test ou le build existant. Cette ligne de base évite d’attribuer à un nouveau test une erreur qui existait déjà.

Étape 1 : écrire le contrat sous forme de cas

Décomposez la route en cas observables. Pour POST /api/widgets, vous pourriez lister : création avec un corps valide, refus si un champ obligatoire manque, refus sans authentification et comportement si un identifiant existe déjà. Évitez « teste toute l’API » : ce n’est ni une consigne testable ni un bon périmètre pour une première génération.

Demandez ensuite : « Propose les cas de test pour cette route. N’écris aucun fichier. Distingue les entrées, le code de réponse, le corps attendu et les dépendances à simuler. » L’agent doit d’abord produire un plan, pas modifier votre suite.

Vérification : relisez chaque cas par rapport à votre contrat. Supprimez ceux qui reposent sur une règle non documentée et ajoutez les erreurs métier que l’agent aurait ignorées.

Étape 2 : fournir le contexte de test minimal

Montrez le handler, le schéma de validation et un test représentatif. Indiquez le framework, le dossier autorisé et les dépendances à simuler. La documentation GitHub recommande de fournir du contexte et de demander des scénarios précis, notamment les cas limites et la validation des données ; cela améliore la pertinence d’une proposition, sans la rendre automatiquement correcte.

Une consigne utilisable ressemble à ceci : « Dans le test de POST /api/widgets, prépare un cas valide et deux cas invalides. Utilise le même framework et les mêmes helpers que le fichier voisin. Simule l’accès à la base. Ne modifie pas le handler. Montre le diff et explique chaque assertion. »

Vérification : lisez le diff. Contrôlez que le test utilise les conventions du projet et qu’il n’ajoute pas une bibliothèque ou un accès réseau réel sans justification.

Étape 3 : vérifier les assertions, pas seulement les statuts

Un test qui vérifie uniquement 200 ou 400 est rarement suffisant. Pour le cas valide, vérifiez le corps retourné, l’effet attendu et l’absence d’effet inattendu. Pour un cas invalide, vérifiez que le bon code est renvoyé et que l’écriture ou l’appel externe n’a pas eu lieu.

Les mocks servent à isoler une dépendance comme une base ou un service HTTP. Ils ne doivent pas imiter le comportement que vous cherchez précisément à tester. Si vous configurez un mock pour toujours renvoyer le résultat espéré, le test ne prouve plus que le handler gère réellement le cas.

Vérification : modifiez temporairement une valeur dans le handler ou dans l’assertion sur votre branche locale pour vous assurer que le test échoue lorsqu’il le devrait. Annulez ensuite ce test manuel. Cette pratique révèle les tests qui passent sans contrôler le comportement visé.

Étape 4 : exécuter le plus petit test puis élargir

Lancez d’abord le fichier concerné avec la commande habituelle du projet. Exemple générique :

pnpm test -- path/to/widgets.test.ts

La commande exacte dépend de votre outillage ; ne copiez pas cet exemple si votre projet utilise un autre script. Lisez la sortie complète. Un test vert confirme seulement les assertions exécutées, pas toutes les exigences de l’API.

Lorsque le test ciblé passe, lancez le contrôle plus large prévu par l’équipe. Gardez la sortie ou le lien vers la CI dans la revue. Si un test échoue, fournissez à l’agent le message minimal utile et demandez une hypothèse ; ne le laissez pas remplacer plusieurs fichiers au hasard.

Vérification : comparez le résultat avec la ligne de base et assurez-vous que le test n’a pas modifié une ressource partagée ou appelé un service réel.

Étape 5 : compléter les cas réellement risqués

Les suggestions générées couvrent souvent le chemin nominal avant les frontières. Ajoutez les données vides, les types incorrects, les autorisations absentes, les erreurs de dépendance et les doublons pertinents. Pour une API paginée, testez aussi les bornes. Pour une API qui écrit, vérifiez l’idempotence ou le comportement attendu lors d’une répétition.

Ne demandez pas à l’agent de deviner les règles d’un abonnement, d’un paiement ou d’une permission. Fournissez une spécification validée ou marquez le cas comme à clarifier. Une ambiguïté produit un test qui peut verrouiller par erreur le mauvais comportement.

Problèmes fréquents et solutions

Les tests générés utilisent la mauvaise bibliothèque

Montrez un test existant et réaffirmez le fichier autorisé. N’introduisez pas une seconde bibliothèque uniquement parce qu’une suggestion la choisit.

Le test passe même quand l’API est cassée

Vérifiez les mocks et les assertions. Testez que l’effet externe n’est pas appelé sur erreur et que la réponse contient les éléments réellement attendus.

L’agent propose d’appeler une API tierce réelle

Refusez la proposition. Utilisez un mock, un environnement isolé ou un serveur de test contrôlé. Les tests reproductibles ne doivent pas dépendre d’un compte externe, d’un quota ou de données inconnues.

FAQ

Un agent IA peut-il écrire tous les tests de mon API ?

Il peut accélérer le squelette et suggérer des cas, mais les règles métier, les assertions et la revue restent de votre responsabilité.

Faut-il tester chaque code HTTP ?

Testez les codes qui représentent un contrat important. Une multiplication de tests superficiels vaut moins que quelques cas qui vérifient les effets et les erreurs réelles.

Les mocks sont-ils toujours nécessaires ?

Non. Ils sont utiles pour isoler des dépendances externes. Un test d’intégration peut volontairement utiliser une dépendance contrôlée pour vérifier leur interaction.

Puis-je copier une commande proposée par l’agent ?

Lisez-la avant de l’exécuter et adaptez-la aux scripts du projet. Une commande peut installer, modifier ou supprimer des éléments ; un agent ne remplace pas cette vérification.

Comment savoir si la couverture est suffisante ?

Reliez les tests aux comportements et risques définis dans le contrat. Une métrique de couverture peut aider, mais elle ne prouve pas à elle seule la qualité des scénarios.

Conclusion

Un agent IA est utile pour tester une API quand il travaille à partir d’un contrat explicite et d’exemples du dépôt. Planifiez les cas, relisez le diff, vérifiez les assertions et exécutez les tests avant d’accepter le résultat.

Sources et limites

Les suggestions d’un agent sont non déterministes et les capacités varient selon l’outil et le plan. Ce tutoriel ne remplace pas une stratégie de test ni une revue de sécurité.