Le Test-driven development, un outil parmi d'autres

Spoiler alert : ici, on enfonce des portes ouvertes.

Le Test-driven development  (TDD) suscite des crispations que je ne m'explique pas tout à fait. Rapidement, le débat se polarise avec l'idée que, parce qu'on est adepte de cette méthode, on entendrait forcément l'utiliser partout et pour tout.

Le cas d'application parfait du TDD, c'est le cœur-domaine de l'application, là où se concentre toute la logique métier. Si vous travaillez en Architecture hexagonale, c'est tout le code à l'intérieur de l'hexagone. A dire vrai, je ne sais plus faire autrement tant cette méthode est synonyme de sécurité et de rapidité dans ma propre expérience.

En dehors de cela, rien de systématique. On ne le dira jamais assez : le TDD est là pour vous aider. S'il vous trouvez qu'il ne vous aide pas, ce n'est peut-être pas le bon outil, ou bien vous l'utilisez mal. Dans tous les cas, soyez critique, faites-vous confiance et ajustez le tir.

Soyons concrets : vous utilisez React ; est-il pertinent de développer vos composants en TDD ? De mon expérience, non.

Lorsque émerge de la logique d'interaction, de la pagination par exemple, je l'extrais en créant une fonction, pure, que je développe en me laissant guider par les tests (TDD).

Mais pour le reste, s'il s'agit de vérifier qu'une callback est bien appelée lorsqu'on clique sur le bouton, effectuer le test manuellement dans le navigateur me paraît bien plus efficace que de faire du TDD à tout prix. En n'omettant pas de capturer le comportement une fois que le résultat est bon : simple snapshot, test d'interaction en mockant le DOM ou bien encore test end-to-end , selon le cas. Du test-after, donc.

Au final, ça n'est pas du TDD, mais les bénéfices sont là :

Ce n'est pas du TDD, et alors ? Seuls comptent le résultat et la Developer eXperience (DX).

Quand on découvre le TDD, il est courant d'avoir la foi du nouveau converti, c'est-à-dire l'envie de l'utiliser partout et pour tout, surtout quand il ne faudrait pas. Illustration parfaite de la loi de l'instrument , qui dit en substance que si la seule chose dont vous disposez est un marteau, vous aurez tendance à ne voir que des clous.

La notion de pyramide de tests  met justement l'accent sur la nécessité d'apprendre à manier les différents types de tests. Ne faire que des tests unitaires ne donnerait pas toutes les garanties nécessaires. Ne faire que des tests end-to-end serait parfaitement inefficace, que dis-je : ce serait une hérésie.

Ainsi, apprendre le TDD ne demande que peu de temps. Apprendre à distinguer les cas dans lesquels il est opportun de s'en servir et les autres prend nettement plus de temps. L'artisan logiciel possède une grande boîte à outils, son art consiste à les utiliser à bon escient.