Ce billet est issu d'une réflexion suite à la discussion de la dernière rencontre Software Craftmanship sur le TDD brainless, i.e. le TDD où l'on ne fait qu'implémenter bêtement le strict minimum nécessaire pour valider chaque test, sous une forme suivante :

def tests(): # mes tests
    assertEqual(my_func(entree1), sortie1)
    assertEqual(my_func(entree2), sortie2)
    assertEqual(my_func(entree3), sortie3)

def my_func(entree): # ma fonction
    if (entree == entree1):
        return sortie1
    if (entree == entree2):
        return sortie2
    if (entree == entree3):
        return sortie3

Le principe du TDD est bien d'implémenter le strict minimum pour passer les tests, mais de façon paresseuse, pas de façon bête. Autrement dit, on implémente de la façon qui nous demande le moins de travail possible. Le TDD brainless ne permet pas cela, puisque, avec la méthode donnée ci-dessus en exemple, on devra implémenter N conditions if pour chacun des N tests, ce qui est relativement rapide quand on a très peu de tests à faire, mais bien plus fastidieux quand on en a beaucoup. Justement, le TDD paresseux consiste à se dire que puisque la méthode est fastidieuse, il faut chercher un moyen de passer les tests de façon plus économique, ce qui entraîne nécessairement une réflexion (d'où la différence avec le TDD brainless) sur un algorithme permettant d'implémenter la fonction testée sans trop d'efforts. À la fin, on arrive donc à une fonction implémentée de façon minimale qui passe les tests, et qui (si les tests ont été bien choisis) fonctionne, contrairement à une fonction implémentée avec du TDD brainless, qui ne fonctionne que pour les cas de tests.

Tout ça pour dire que non, pousser la logique du TDD jusqu'au bout ne donne pas nécessairement du TDD brainless.