Le TDD est avant tout une méthode de développement permettant de faire émerger son design et donc son code grâce aux tests

“Baby-step”, c’est la clé pour s’amuser, pas au sens d’enfantillage, mais pour prendre plaisir à développer et comprendre que notre métier est vraiment beau quand on supprime toute forme de “hasard”.

Un cycle TDD "Red, Green, Refactor" correspond une une bribe de spécification écrit sous forme de test et sa réponse. On écrit le code minimaliste pour que ce test "Red" fonctionne et passe au "Green".

Pour cela, il est recommandé d'abuser de son IDE. Par sa construction itérative guidée par les tests, TDD apporte par “effet de bord” un taux de couverture de code par les tests à 100%. Ce n’est pas ce que l’on recherche de prime abord, mais ce code coverage est là, et surtout il est pertinent. C’est ce dernier mot qui est important : cette pertinence permet réellement de se plonger dans la troisième phase de TDD.

Ensuite on refactorise pour donner plus de sens: spécifier les erreurs, de passer d'un constructuer à un builder, ... Nous pouvons nous le permettre car les tests nous soutiennent. Ils seront aussi à évoluer, par exemple pour vérifier que le builder pattern fonctionne correctement.