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

Spoiler alert : ici, on enfonce des portes ouvertes.

Le sujet du 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.

Je le rappelle souvent lors des formations et des séances de coaching : 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.

Lorsqu'émerge de la logique d'interaction (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 e2e, selon le cas. Du test-after, donc.

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

• Durant la phase de développement, des baby steps et un feedback rapide afin de ne pas accumuler les bugs ;

• Un code testé, pour éviter les régressions ;

• Un code documenté, par les tests.

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

En revanche, le cœur-domaine de l'application se prête parfaitement au TDD. 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.

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. Idem pour les tests d'intégration entre les deux.

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. Tout l'art est de savoir utiliser chaque outil à bon escient.