Tests manuels agentiques

Tests manuels agentiques

Caractéristiques des agents de codage

La caractéristique principale d'un agent de codage est sa capacité à exécuter le code qu'il écrit. Cela rend les agents de codage beaucoup plus utiles que les LLM qui se contentent de produire du code sans possibilité de le vérifier.

Il ne faut jamais supposer que le code généré par un LLM fonctionne tant qu'il n'a pas été exécuté.

Les agents de codage peuvent confirmer que le code qu'ils ont produit fonctionne comme prévu, ou itérer sur ce code jusqu'à ce qu'il le fasse.

Importance des tests unitaires

Amener les agents à écrire des tests unitaires, en particulier en utilisant la méthode TDD (Test-Driven Development), est un moyen puissant de s'assurer qu'ils ont bien exercé le code qu'ils écrivent.

Cependant, ce n'est pas la seule approche valable.

Le fait qu'un code passe des tests ne signifie pas qu'il fonctionne comme prévu. Quiconque a travaillé avec des tests automatisés a vu des cas où tous les tests réussissent mais où le code échoue de manière évidente - il peut faire planter le serveur au démarrage, ne pas afficher un élément crucial de l'interface utilisateur, ou manquer un détail que les tests n'ont pas couvert.

Les tests automatisés ne remplacent pas les tests manuels. J'aime voir une fonctionnalité fonctionner de mes propres yeux avant de l'intégrer dans une version.

J'ai constaté qu'amener les agents à tester manuellement le code est également précieux, révélant fréquemment des problèmes qui n'ont pas été détectés par les tests automatisés.

Mécanismes pour les tests manuels agentiques

La manière dont un agent doit tester "manuellement" un morceau de code varie en fonction de ce que ce code est.

Pour les bibliothèques Python, un modèle utile est python -c "... code ...". Vous pouvez passer une chaîne (ou une chaîne multilignes) de code Python directement à l'interpréteur Python, y compris du code qui importe d'autres modules.

Les agents de codage sont tous familiers avec cette astuce et l'utiliseront parfois sans y être incités. Cependant, leur rappeler de tester en utilisant python -c peut souvent être efficace :

• Essayez cette nouvelle fonction sur des cas limites en utilisant python -c

D'autres langages peuvent avoir des mécanismes similaires, et s'ils n'en ont pas, il est toujours rapide pour un agent d'écrire un fichier de démonstration, puis de le compiler et de l'exécuter. J'encourage parfois à utiliser /tmp uniquement pour éviter que ces fichiers ne soient accidentellement engagés dans le dépôt plus tard.

• Écrivez du code dans /tmp pour essayer des cas limites de cette fonction, puis compilez et exécutez-le

De nombreux projets impliquent la construction d'applications web avec des API JSON. Pour ceux-ci, je dis à l'agent de les tester en utilisant curl :

• Exécutez un serveur de développement et explorez cette nouvelle API JSON en utilisant curl

Dire à un agent d' "explorer" entraîne souvent des essais de différents aspects d'une nouvelle API, ce qui peut rapidement couvrir beaucoup de terrain.

Si un agent trouve quelque chose qui ne fonctionne pas lors de ses tests manuels, j'aime lui dire de le corriger avec le TDD rouge/vert. Cela garantit que le nouveau cas est couvert par les tests automatisés permanents.

Utilisation de l'automatisation des navigateurs pour les interfaces web

Avoir une procédure de test manuel en place devient encore plus précieux si un projet implique une interface web interactive.

Historiquement, ces interfaces ont été difficiles à tester par le code, mais la dernière décennie a vu des améliorations notables dans les systèmes d'automatisation des véritables navigateurs web. Exécuter un véritable navigateur Chrome, Firefox ou Safari contre une application peut révéler toutes sortes de problèmes intéressants dans un cadre réaliste.

Les agents de codage savent comment utiliser ces outils extrêmement bien.

Le plus puissant d'entre eux aujourd'hui est Playwright, une bibliothèque open source développée par Microsoft. Playwright offre une API complète avec des liaisons dans plusieurs langages de programmation populaires et peut automatiser n'importe quel moteur de navigateur populaire.

Dire simplement à votre agent de "tester cela avec Playwright" peut suffire. L'agent peut alors sélectionner la liaison de langage qui a le plus de sens, ou utiliser l'outil playwright-cli de Playwright.

Les agents de codage fonctionnent très bien avec des CLIs dédiées. agent-browser par Vercel est un wrapper CLI complet autour de Playwright spécialement conçu pour être utilisé par les agents de codage.

Mon propre projet Rodney sert un objectif similaire, bien qu'il utilise le Chrome DevTools Protocol pour contrôler directement une instance de Chrome.

Voici un exemple de prompt que j'utilise pour tester des choses avec Rodney :

• Démarrez un serveur de développement, puis utilisez uvx rodney --help pour tester la nouvelle page d'accueil, regardez les captures d'écran pour confirmer que le menu est au bon endroit

Il y a trois astuces dans ce prompt :

• Dire "utilisez uvx rodney --help" amène l'agent à exécuter rodney --help via l'outil de gestion de paquets uvx, qui installe automatiquement Rodney la première fois qu'il est appelé.

• La commande rodney --help est spécifiquement conçue pour donner aux agents tout ce dont ils ont besoin pour comprendre et utiliser l'outil. Voici ce texte d'aide.

• Dire "regardez les captures d'écran" suggère à l'agent qu'il doit utiliser la commande de capture d'écran de Rodney et lui rappelle qu'il peut utiliser ses propres capacités visuelles sur les fichiers d'image résultants pour évaluer l'apparence visuelle de la page.

C'est beaucoup de tests manuels intégrés dans un court prompt !