Le TDD et la Méthode Scientifique
Notre beau métier de développeur logiciel est un métier complexe. C’est avant tout un travail d’exploration, en avançant par petits pas, en reculant parfois, pour mieux sauter ensuite.
Qui dit exploration dit nécessité d’apprendre. De nos erreurs, de ce qui a fonctionné, etc.
L’exploration, c’est aussi savoir avancer au sein de la complexité intrinsèque au développement logiciel.
Pour être un bon développeur logiciel, il faut donc :
devenir expert en apprentissage
devenir expert en gestion de la complexité
Bien évidemment, ce métier n’est pas le premier à faire preuve de ce genre de problématique. Et ce processus d’avancer en apprenant, tout en gérant la complexité, est un processus bien connu : la méthode scientifique
Qu’est-ce que la méthode scientifique
Quel rapport entre le développement logiciel et la méthode scientifique ? Définissons tout d’abord ce qu’est la méthode scientifique avec des mots simples. Il s’agit de :
caractériser en observant un état initial
émettre une hypothèse sur le pourquoi de cet état initial
prédire le futur état du système
expérimenter pour tester la solution
tirer les conclusions de notre expérience
Dans cette dernière étape, on apprend ainsi à définir si nos hypothèses de base étaient bonnes ou mauvaises.
La méthode scientifique est donc une excellente méthode pour apprendre à petits pas, pour faire correctement notre travail. C’est de l’ingénierie pure et dure.
Observer un état initial, imaginer le résultat d’une action, avancer par petits pas, ça ne vous rappelle rien ? Eh oui ! C’est très proche de la démarche TDD ! Et ce n’est pas un hasard.
Le TDD comme approche scientifique de l’ingénierie logicielle
Rappelons-le, l’objectif du TDD est de s’assurer que l’on écrit du code qui fonctionne comme on l’avait prévu, selon des spécifications claires sur ce comportement, établis en amont du code.
La démarche est alors très similaire à la méthode scientifique. Mettons que l’on veuille tester l’ajout de produit à un panier, si l’on prend les étapes de la méthode scientifique vues plus haut, cela donne :
caractériser => définir un état initial du système que l’on veut tester : mon panier n’a pas de produit
émettre une hypothèse => lorsque j’ajoute un produit dans mon panier, mon panier contient alors ce produit : c’est la spécification du test
prédire le futur état du système => écrire l’assertion alors que l’on n’a pas encore écrit le code
tirer les conclusions => le test ne passe pas, car le code n’est pas implémenté. On écrit un peu de code pour faire passer le test, et on recommence.
Ce n’est pas un hasard si le TDD ressort dans les études comme étant une pratique amenant la production de meilleurs logiciels, plus rapidement. C’est simplement la méthode que tout bon ingénieur applique dans son domaine d’ingénierie. Et il n’y a aucune raison pour que notre domaine d’ingénierie n’en profite pas non plus :)
Happy Coding !