Comment vérifier la gestion des erreurs rédigée par votre agent de codage

Votre agent de codage indique qu’il a ajouté des nouvelles tentatives et une gestion des limites de débit, et que ses tests réussissent. Avant de faire confiance à cela, vérifiez contre quoi les tests ont été exécutés.

Dans un test que nous avons exécuté avec 3 agents de codage (210 exécutions), nous leur avons demandé de gérer les échecs d’API et de montrer que cela fonctionne. Dans 76 % des 140 exécutions qui ont demandé du code fonctionnel, l’agent a reproduit la panne à la main avec des stubs de fetch, httpx.MockTransport ou un serveur HTTP temporaire. Dans les 75 exécutions où l’API réelle était disponible et l’invite ne l’a pas exclue, aucune n’a testé l’application sur sa véritable URL d’API. La réussite de tests comme ceux-ci prouve que le code de l’agent gère l’échec imaginé par l’agent. Il s’agit d’une erreur différente de celle que l’API envoie.

Liste de contrôle

  1. Demandez contre quoi cela a été testé. Demandez à l’agent : « Quelle URL l’application a-t-elle appelée pendant votre test, et qu’est-ce qui a renvoyé l’erreur ? » Si la réponse est un stub ou un serveur local qu’il a écrit, traitez les tests en tant que tests unitaires des branches qu’il a ajoutées.
  2. Recherchez les interrupteurs ajoutés pour les tests. Recherchez dans le diff les nouvelles variables d’environnement, les paramètres d’URL de base ou les flags. Dans notre test, 61 des 105 exécutions sur des applications qui appellent GitHub, OpenAI ou une API météo en ont ajouté une. Déterminez si vous le souhaitez en production.
  3. Vérifiez le code par rapport au comportement documenté de l’API. Chaque API échoue de sa propre façon :
    • GitHub : lorsque vous dépassez la limite de débit principale, vous obtenez 403 ou 429 avec x-ratelimit-remaining défini sur 0, et vous attendez jusqu’à l’heure indiquée dans x-ratelimit-reset, en secondes d’époque UTC. Pour les limites de taux secondaires, attendez retry-after si elle est là, sinon jusqu’à x-ratelimit-reset si x-ratelimit-remaining est 0, sinon au moins 1 minute. Le code qui vérifie uniquement les 429 manque les 403.
    • OpenAI : certains codes 429 concernent les limites de facturation et de dépense, comme credit_balance_exhausted. Réessayer ne servira à rien. Le code qui réessaie après chaque erreur 429 vous cache le problème.
    • Anthropic : la limite de dépense 429 n’a pas retry-after d’en-tête, et en cas de surcharge, 529 est renvoyé, ce à quoi le code qui connaît uniquement les codes d’état standard peut ne pas s’attendre.
  4. Vérifiez comment cela se lit Retry-After. L’en-tête contient un nombre de secondes ou une date HTTP (RFC 9110). Vérifiez que le code gère le format envoyé par votre API, limite le nombre de tentatives et l’attente totale, et n’effectue pas de nouvelles tentatives par-dessus un kit de développement logiciel (SDK) qui effectue déjà des tentatives de nouvelle tentative.
  5. Vérifiez ce que l’utilisateur voit lorsque les tentatives sont épuisées. Recherchez un message clair au lieu d’une trace de pile ou d’un spinner sans fin, puis vérifiez que l’utilisateur ne perd pas son travail.
  6. Exécutez l’application avec ses URL réelles et des pannes simulées. Il s’agit de la seule étape qui montre comment l’application en cours d’exécution, son Kit de développement logiciel (SDK) et sa stratégie de nouvelle tentative se comportent ensemble.

Comment vérifier la gestion des erreurs générée par l’agent

Approach Ce que vous trouvez Ce qui vous manque
Lire le diff Si le code semble correct Qu’il se comporte correctement par rapport aux réponses réelles de l’API
Exécuter les tests de l’agent Que les branches de code qu’il a écrites fonctionnent Tout ce que le stub n’a pas modélisé : codes d’état réels, en-têtes, corps d’erreurs et nouvelles tentatives du Kit de développement logiciel (SDK)
Appeler l’API réelle jusqu’à ce qu’elle échoue Comportement réel Vous ne pouvez pas déclencher d’échecs à la demande, et vous dépensez un quota réel
Exécuter l’application sur des URL réelles avec des échecs simulés Comment l’application en cours d’exécution, son Kit de développement logiciel (SDK) et sa stratégie de nouvelle tentative gèrent les erreurs propres à l’API Votre code isolé. Conservez les tests unitaires de l’agent pour cela.

Essayez-le dans votre application

Dev Proxy intercepte les demandes envoyées par votre application à l’API réelle et retourne les erreurs que vous choisissez, sans aucune modification du code de votre application. Pour les API populaires, commencez par un préréglage. Pour vérifier la gestion de la limite de débit GitHub que votre agent a écrite :

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"

Exécutez votre application et regardez la sortie de Dev Proxy. Le préréglage renvoie un code 429 avec les en-têtes de limite de requêtes de GitHub une fois que votre application dépasse la limite. Le RetryAfterPlugin dans le préréglage vous indique si votre application appelle à nouveau l’API avant que le délai d’attente ne soit écoulé. Les openai-throttling préréglages et anthropic-throttling font de même pour les erreurs de limite de débit de requêtes du fournisseur, et openai-throttling retourne également une credit_balance_exhausted réponse HTTP 429 qui ne doit pas être retentée.

Pour les autres API :

Vous pouvez également demander à votre agent de codage d’écrire la configuration de Dev Proxy. Ajoutez le serveur MCP Dev Proxy à votre agent afin qu’il puisse rechercher la documentation et les bonnes pratiques de Dev Proxy et vérifier la version que vous avez installée. Passer en revue cette configuration comme tout autre code écrit par l’agent.

Pour installer Dev Proxy, consultez Configurer Dev Proxy.

Étapes suivantes

Tester mon application avec des erreurs aléatoires

Voir aussi

  • Dernière mise à jour :