"Évidemment c'est un peu bricolé, mais ça nous permettra de tenir la démo de vendredi, et de convaincre le sponsor. Ensuite, on revient à notre état de l'art, avec une implémentation plus robuste." Au commencement la dette technique, c'était cela: une métaphore bien pratique pour désigner le geste agile qui consiste à dégrader temporairement son état de l'art afin d'atteindre un objectif intermédiaire. Mais ça, c'était avant. Maintenant la dette technique est synonyme de code écrit à l'arrache. "Dans ce projet, il y a zéro test, le code est rempli de copiers/collers, on y comprend rien, les méthodes font plusieurs centaines de lignes, c'est ni fait ni à faire." La dette technique, il y a maintenant des consultants -- et des outils automatiques -- pour vous la calculer en euros ! En vérité, la Dette  Technique, ce n'est pas de la dette, et ce n'est pas technique...

En tant que pratiquants de l'approche TDD et fan tests en général, nous savons qu'il est relativement aisé de faire du TDD sur une “page blanche” ( nouveau projet, nouvelle classe, nouvelles fonctionnalités) mais que, sorti du cadre des tutoriels, "dans la vraie vie", ce n'est pas "si simple".
La vraie vie c'est le Legacy avec ses dépendances, ses code smells, ses multiples choix d'architectures, les deadlines etc..
Encourager l'écriture du code en commençant par les tests dans ce contexte peut paraître impossible aux équipes de dev sans une période de "freeze" plus ou moins longue. Pour ne plus risquer d'effrayer les collègues dev et non dev, nous vous proposons d'apprendre à sortir de l'ornière du legacy par l'écriture de tests de capture mais pas que.