Développement piloté par les tests

TDD est la boucle rouge → verte. Cette compétence est la référence qui permet à cette boucle de produire des tests qui méritent d'être conservés : ce qu'est un bon test, où vont les tests, les anti-modèles et les règles de la boucle. Chaque section s'applique à chaque cycle — consultez-les avant et pendant la boucle, pas après.

Lorsque vous explorez la base de code, lisez CONTEXT.md (s'il existe) afin que les noms des tests et le vocabulaire de l'interface correspondent à la langue du domaine du projet et respectent les ADR dans la zone que vous touchez.

Qu'est-ce qu'un bon test

Les tests vérifient le comportement via des interfaces publiques, et non les détails d'implémentation. Le code peut changer entièrement ; les tests ne devraient pas le faire. Un bon test se lit comme une spécification — « l'utilisateur peut payer avec un panier valide » vous indique exactement quelle fonctionnalité existe — et survit aux refactorisations car il ne se soucie pas de la structure interne.

Voir tests.md pour des exemples et mocking.md pour des directives moqueuses.

Coutures — où vont les tests

Une couture est la limite publique que vous testez : l'interface où vous observez le comportement sans accéder à l'intérieur. Les tests sont à rude épreuve, jamais contre les internes.

Testez uniquement sur des coutures préalablement convenues. Avant d'écrire un test, notez les coutures testées et confirmez-les avec l'utilisateur. Aucun test n'est écrit sur une couture non confirmée. Vous ne pouvez pas tout tester : convenir dès le départ des coutures est la façon dont les efforts de test se concentrent sur les chemins critiques et la logique complexe au lieu de chaque cas limite.

Demandez : "Qu'est-ce que l'interface publique et quelles coutures devrions-nous tester ?"