Je suis complètement en phase avec toi.
Peut-être un petit détail…
Si tu appliques la règle stricte qui veut que tu n’écris tu code en production que s’il fait passer un test, ta couverture de code sera de 100%. Surveiller ta couverture montre ainsi que tu as transgressé cette règle et te permet éventuellement d’accroitre ta base de test, donc ta confiance.
Autre petit détail sur ton assertion « Donc si j’estime avoir un doute sur un cas précis, je n’hésite pas à écrire le test qui correspond. Pour réduire ma peur, et augmenter ma confiance. ». Ce n’est pas lié au TDD, c’est également vrai si l’on fait « simplement » du test Image may be NSFW.
Clik here to view.
C’est d’ailleurs aussi le cas pour la compréhension d’une nouvelle lib ou techno. On fait des tests pour comprendre, ce n’est pas spécifiquement du TDD…
Dernier point, TDD permet d’avoir du code… testable, donc « propre » selon certains critères. Ça a clairement un impact sur la façon d’écrire le code, on parle donc bien de Design. Et la « maitrise du coût du changement » est un point vraiment crucial.
En revanche, le lien avec les défauts est assez « discutable », une fois que l’on aura discuté de ce qu’est un défaut Image may be NSFW.
Clik here to view.
Il reste pour moi le problème des tests d’intégration souvent décrié par les puristes du TDD qui avancent que ces tests sont trop couteux et vont finir par tuer l’application. Personnellement, je ne suis pas assez avancé dans ces pratiques pour m’en passer. J’essaie de faire du code testable avec des tests unitaires et des mocks. Mais quand je les mets ensemble, le comportement peut être assez… inattendu Image may be NSFW.
Clik here to view.
