Structuré avec Claude

TDD avec l’IA

Le TDD — Test-Driven Development — repose sur un principe contre-intuitif : on écrit les tests avant le code. Pas pour vérifier que ça marche après, mais pour définir ce qu’on attend avant même de commencer à implémenter.

Le cycle classique tient en trois étapes :

Red — le test échoue parce que le code n’existe pas encore. C’est normal, c’est voulu. Green — on implémente le strict minimum pour que le test passe. Refactor — on améliore le code sans changer le comportement, les tests garantissant qu’on ne casse rien.

Adapté à l’IA

Avec Claude dans la boucle, le cycle se déplace. La question n’est plus “est-ce que je sais écrire ce test ?” mais “qui écrit quoi, et à quel moment ?”

Trois patterns émergent selon le contexte :

Tu écris les tests, Claude implémente — tu définis le comportement attendu, Claude produit le code qui le satisfait. C’est le TDD le plus pur avec IA : les tests sont ta spec, Claude est ton implémenteur.

Claude écrit les tests, tu valides, Claude implémente — utile quand tu maîtrises moins le domaine. Claude propose les cas de test, tu vérifies qu’ils couvrent ce qui compte, puis il implémente. Le risque : valider des tests qui semblent corrects sans voir ce qu’ils ne couvrent pas.

Les deux en dialogue — tu décris le comportement attendu en langage naturel, Claude traduit ça en tests, vous affinez ensemble, puis il implémente. Plus lent, mais plus pédagogique si tu veux comprendre ce que les tests font.

Ce que ça change

Sans TDD, le flux classique avec Claude ressemble à : “écris-moi une fonction qui fait X” → Claude produit quelque chose → ça marche dans les cas évidents → les edge cases apparaissent plus tard.

Avec TDD, les edge cases sont définis avant. Le test qui couvre le cas null, la liste vide, la valeur limite — il existe déjà quand Claude commence à implémenter. Claude ne peut pas les ignorer.

Ça change aussi la nature du dialogue. Au lieu de corriger le code après coup, on corrige les attentes avant. C’est plus lent au départ, plus solide ensuite.

Par où commencer

Si tu n’as pas l’habitude du TDD, inutile de tout changer d’un coup. Un point d’entrée simple :

Sur ta prochaine feature, avant de demander à Claude d’implémenter, dis-lui :

Avant d'écrire le code, écris les tests unitaires pour cette fonction.
Décris les cas nominaux, les cas limites, et les cas d'erreur.
Je valide les tests avant que tu implémentes.

Tu verras rapidement si les tests qu’il propose couvrent ce que tu avais en tête — et souvent, ils révèlent des cas auxquels tu n’avais pas pensé.

← Superpowers