Jared Norman réagit à un post Reddit sur la pratique réelle du TDD (Test-Driven Development) en entreprise, soulignant que si les tests sont souvent perçus comme une contrainte, leur valeur dépend de leur pertinence et de leur utilité. Il insiste sur trois points clés : privilégier les cas de failure utiles, éviter les tests redondants ou inutiles, et toujours avoir une raison claire d’écrire un test. Les réactions au post varient : certains développent en TDD surtout pour le backend (plus facile à tester), d’autres écrivent les tests après le code, et quelques-uns utilisent l’IA pour générer des tests—une approche que Jared critique, jugeant les outils actuels peu efficaces pour produire des tests de qualité. Il rappelle que le TDD est un outil parmi d’autres, à adapter selon le contexte (durée de vie du code, complexité, besoin de maintenance), et que l’important est d’en tirer un maximum de valeur, surtout dans des projets à long terme. En résumé, le TDD n’est pas une obligation absolue, mais une méthode qui, bien maîtrisée, peut accélérer le développement et sécuriser les évolutions futures.
Tout est dans le titre
Le résumé de 3 conférences
- Les classes abstraites c’est fini (et c’est la faute à TDD)
- 🧑🎤🎸 La preuve de programme vous fera apprécier les tests
- (Re)devenez pote avec le CSS.
Uncle Bob explique les similitudes et les différences entre la comptabilité à double entrée et le TDD.
Tout est dans le titre
Tout est dans le titre
Un article très complet
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
De l'importance des tests !
Tout est dans le titre
Des recommandations sur le TDD
L'auteur explique comment bien pratiquer le TDD, en pensant à l'architecture de son code et de ses tests
Ça a l'air de ressembler plus que furieusement au BDD (Behavior Driver Development), présenté comme ça
Pour résumer l'article, si vous ne pratiquez pas le TDD avec rigueur (typiquement, si vous créez vos tests après avoir écrit votre code), utilisez au moins des outils comme pitest (en Java) pour faire des tests "de mutation"...
Contrairement au refactoring (ne pas changer le comportement du code), il s'agit ici de le changer. L'auteur montre différents "patterns" et les tests unitaires qui correspondent...