Skip to content
PKResources
EN
Plan de la formation

Ingénierie agentique : la formation pratique · Module 4: Les boucles de vérification

Les tests, boussole de l’agent (TDD avec des agents)

Un agent ne vise que ce qu’il peut vérifier. Écrivez d’abord le test qui échoue, verrouillez-le, puis laissez l’agent itérer jusqu’au vert sans y toucher.

Leçon 13 / 24 · ⏱ 8 min

Un agent sans vérification devine, et il vous dira que sa devinette a marché. Un agent avec un test qui échoue a une direction, une ligne d’arrivée et un moyen de remarquer ses propres erreurs.

C’est pourquoi je considère les tests comme l’intrant le plus important d’une exécution d’agent. Plus important que le prompt.

Pourquoi un test rouge bat un bon prompt

Un prompt décrit ce que vous voulez avec des mots, et les mots sont ambigus. Un test qui échoue le décrit avec un code de sortie. L’agent peut le lancer, lire l’échec, changer quelque chose et recommencer autant de fois qu’il le faut, sans vous dans la boucle.

  1. RougeUn test qui échoue pour la bonne raison
  2. VerrouillerVous relisez et faites un commit du test
  3. L’agent itèreModifier, lancer, lire l’échec, recommencer
  4. VertLe test passe, fichier de test intact
  5. RefactoriserNettoyer avec la suite comme filet

↺ Un comportement par boucle

Le TDD classique, avec un changement : l’humain possède l’étape rouge, l’agent possède le vert.

Qui écrit le test?

Vous n’avez pas à écrire chaque test vous-même. Mais vous devez en être propriétaire. Si l’agent écrit le test et le code d’un seul coup, un malentendu est encodé deux fois, et le test confirme joyeusement le bogue.

✕ L’agent écrit test et code ensemble

  • –Un seul prompt : « ajoute la fonctionnalité avec des tests »
  • –Les tests épousent ce que le code a fini par faire
  • –Valeurs attendues copiées de la sortie de l’implémentation
  • –Tout est vert, rien n’est prouvé

✓ Le test d’abord, le code ensuite

  • +L’agent (ou vous) rédige les tests à partir de la spec, rien d’autre
  • +Vous les lisez, corrigez les valeurs attendues, les lancez : rouge
  • +Vous faites un commit des tests avant que l’implémentation existe
  • +L’agent implémente avec « ne modifie pas les fichiers de test »

Le brief que j’utilise

Deux courtes exécutions. La première produit seulement les tests; la deuxième les fait passer.

Exécution 1 — tests seulement
Écris des tests qui échouent pour : annuler une commande rembourse
le montant complet si l'annulation a lieu dans les 24 heures, et 50 %
après ce délai.
Place-les à côté des tests de commande existants et suis leur style.
N'écris et ne modifie aucun code d'implémentation.
Arrête quand les tests s'exécutent et échouent parce que le
comportement manque.

Exécution 2 — implémentation
Fais passer les tests de orders/cancel.test.
Ne modifie, ne saute et ne supprime aucun test. Si tu crois qu'un test
est faux, arrête et explique pourquoi au lieu de le changer.
Terminé quand : toute la suite de tests passe.

Pour un refactoring, inversez : demandez d’abord à l’agent des tests de caractérisation qui figent le comportement actuel, faites-en un commit, puis refactorisez en vous appuyant sur eux. On verra à la leçon 4.4 ce qui arrive quand un test n’est pas verrouillé.

Testez-vous

🧠 Tests et agents

Pointage: 0 / 4

  1. 1. Pourquoi faire un commit des tests qui échouent avant que l’agent implémente quoi que ce soit?

  2. 2. Votre nouveau test échoue avec « module introuvable ». Que faites-vous?

  3. 3. Quel est le principal risque de « implémente ceci et ajoute des tests » dans un seul prompt?

  4. 4. Vous allez faire refactoriser par un agent un module sans tests. Première étape?

Avant de continuer

✅ À retenir

0 / 5 complété

← PrécédenteDécouper un epic en tâches de taille agentSuivante →Types, linters et rétroaction rapide