🚧 Pourquoi la plupart des développeurs écrivent mal leurs tests unitaires (et comment y remédier) Dans le cadre du TDD ou non, beaucoup de développeurs adoptent une approche courante mais problématique : Considérer une "classe" comme l'unité d'isolation. Selon Uncle Bob (Robert C. Martin), cette pratique découle d'une méprise. On crée souvent une correspondance un-à-un entre les classes de production et de test, en écrivant une méthode de test par méthode de production et en mockant toutes les dépendances, même celles qui n'ont pas de sens à mocker. Logique au départ, cette méthode vise à tester chaque élément du système. Pourtant, elle pose problème. Le couplage structurel est le principal écueil. Lorsque les tests sont liés à la structure interne du code (classes, méthodes), un refactoring comme « modifier une signature de méthode » « déplacer une méthode » ou « diviser une classe » casse les tests. Cela double l'effort : Refactoriser le code est nécessaire, mais réparer les tests devient une perte de temps. Résultat ? Un code difficile à maintenir, des modifications futures coûteuses, et une livraison plus lente, comme le souligne Uncle Bob. L'alternative, prônée par Kent Beck, est de voir le "comportement" comme l'unité d'isolation. Couplons les tests au comportement observable (via l'interface publique) plutôt qu'à la structure interne. Prenons l'exemple d'une classe `OrderProcessor` qui utilise internement `PriceCalculator` et `TaxCalculator`. Testons `OrderProcessor` (ex. méthode `processOrder()`) sans mocker les classes internes, sauf pour les dépendances externes (I/O, non-déterminisme). #Disclaimer : D'ailleurs quand on fait vraiment du TDD, on ne connait nos classes internes qu'au moment du REFACTORING ...Cela rend les tests robustes face aux refactorings, réduisant les coûts d'entretien et accélérant la livraison. En pratique, une seule classe de test (`OrderProcessorTest`) suffit pour la classe publique, préservant la couverture de code. Comme le dit Kent Beck : "Les tests doivent être couplés au comportement du code et découplés de sa structure." --- J'ai fait du TDD en Live devant 1 Développeur récemment et depuis il commence à utiliser cette approche qui semble efficace et participe à une meilleure maintenabilité. Halloween TDD Mode 🎃 #TDD #TestUnitaires #Refactoring