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.