Les tests sont le premier client de notre code. Ils nous donnent un feedback quasi immédiat sur le comportement du système testé face à un bug ou une nouvelle fonctionnalité à implémenter. Sans tests, les developpeurs sont privés de ce précieux premier feedback.

Pour toujours avoir ce premier feedback rapide, nous avons appris à faire du TDD. Sauf que, le TDD apparaît contre productif dans des refontes de Legacy pour beaucoup de dev.

Car, dans un projet avec du Legacy, l'enjeu est d'abord de (re)comprendre l'existant puis, une fois qu'on a compris, d'écrire des tests automatisés qui documentent le comportement de cet existant ou révèle le bug. Aussi, comment commencer son dev par les tests sur un existant qu'on ne comprend pas encore? Partant d’un kata maison, nous présenterons le principe des tests de capture et de caractérisation qui vous aideront à sécuriser la refonte de votre Legacy.

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.