Table des matières
Ouvrir table des matières
La méthode TDD : c’est quoi et pourquoi ?
Notre cher site Wikipédia 🔗 nous dit la chose suivante : « Test-Driven Development (TDD), ou Développement piloté par les Tests en français, est une méthode de développement de logiciel qui consiste à concevoir un logiciel par petits pas, de façon itérative et incrémentale, en écrivant chaque test avant d’écrire le code source et en remaniant le code continuellement. »
Vous lisez bien. Le cœur de la méthode est d’écrire du test avant d’écrire votre code. C’est donc quelque chose de fondamentalement différent vis-à-vis de ce que vous faites en programmation, mais également par rapport à ce que vous avez appris.
Et là, vous êtes en droit de vous poser la question : comment c’est possible d’écrire des tests avant d’écrire du code ? Et bien, vous allez voir que la théorie est assez simple à comprendre.
Au cœur de la méthode
Comme il est écrit dans la définition, la méthode consiste à avancer de façon itérative et incrémentale que l’on pourrait aussi appeler cycle. Et pour chacun des cycles que vous pouvez être amené à réaliser, il y a 3 étapes à réaliser :
Il y a 3 étapes à réaliser :
- 1er étape : écrire un test qui échoue
- 2ème étape : faire en sorte que votre test passe
- 3ème étape : retravailler le code produit
Et ainsi de suite ! Le but est de réaliser ces étapes sur des parties très courtes pour former de nombreux cycles et ainsi réaliser une fonctionnalité par exemple.
L’excuse du genre “les tests, ça prend trop de temps” ne tient plus puisque les tests font partie intégrante de la méthode et de l’écriture du code.
Un exemple de cycle
Je vais vous montrer un exemple de cycle pour que vous compreniez comment ça se passe concrètement. Supposons que vous souhaitez réaliser une méthode de création pour un nouveau service de gestion des tags d’une application.
1ère étape : écrire un test qui échoue
Il faut donc commencer par écrire votre test. N’oubliez pas que la méthode vous demande d’avancer par petits pas. Il faut donc aller au plus simple. Ici, dans l’exemple, il suffit juste de créer une méthode de création pour un nouveau service.
Dans votre framework de test, vous allez donc commencer par écrire ce genre de test :
Pour notre premier cycle, on va uniquement écrire cela. Il faut écrire rapidement un test qui échoue, et c’est exactement ce qui se passe dans ce code. Le test va automatiquement échouer puisque la méthode “create” n’existe pas dans notre service.
2ème étape : faire en sorte que votre test passe
Vu que notre test échoue, il faut faire en sorte qu’il fonctionne maintenant. Ici cela reste assez simple : on va tout simplement implémenter la méthode dans notre service, puisque celle-ci n’existe pas et que notre test échoue à cause de cela :
Une fois implémenté, on relance simplement notre test pour constater qu’il passe. Fin de la deuxième étape.
3ème étape : retravailler le code produit
Y a-t-il du code à retravailler et qui peut être amélioré ? Pas vraiment, étant donné que nous avons uniquement implémenté une méthode sans y écrire du code. Il n’y a donc pas de refactoring pour cet exemple.
Les prochains cycles par rapport à l’exemple
Je vous ai montré l’exemple d’un cycle où l’on écrit un test qui échoue, puis on fait en sorte qu’il fonctionne pour enfin retravailler le code. Quels sont les prochains cycles ensuite ?
Dans notre exemple, la suite serait d’implémenter du code dans la méthode pour faire ce qu’elle est censée réaliser.
On pourrait, par exemple, faire un cycle pour implémenter des variables d’entrée à la méthode. Puis un autre pour traiter ses données d’entrée, puis pour enregistrer les informations afin d’obtenir une création, etc.
Comprenez-vous le principe ? Vous allez découper le travail de production de code que vous avez l’habitude de réaliser, mais en commençant par les tests et sous forme de cycle.
Voici quelques avantages que j’en retire personnellement :
- Vous allez à l’essentiel. Vous n’écrivez que le minimum requis pour que votre programme fonctionne.
- Votre code est alors plus simple et de meilleure qualité.
- Le fait d’avancer pas à pas va vous aider à écrire votre code plus facilement.
- Le fait de refactorer du code pour chaque cycle va simplifier votre tâche (il est plus facile d’améliorer du code existant que d’écrire du nouveau code depuis zéro).
- Vous réfléchirez beaucoup plus à la logique métier que technique, ce qui améliorera fortement la qualité de l’application d’un point de vue fonctionnel.
- Vous ne testerez que ce qui doit être réellement testé.
L’erreur que vous allez très certainement faire (et c’est normal)
Comme je vous l’ai dit récemment, cela ne fait pas très longtemps que je réalise des tests unitaires pour le code que je produis. Et encore moins avec cette méthode TDD.
Autant vous dire que je n’ai pas encore le pilote automatique pour que cela devienne naturel. Ce sera un travail de longue haleine. Et il y a une erreur que je fais assez souvent avec cette méthode, et que vous risquez également de faire si vous adoptez la méthode.
Sauter des cycles
L’erreur que vous risquez de faire se situe au niveau de vos cycles. Il pourra vous arriver de commencer à réaliser un cycle et de rester bloqué à la deuxième étape, à savoir faire en sorte que le test passe.
Vous vous dites, comment ? Et bien, dans mon cas, c’est à cause du code. Il m’arrive de me disperser dans mon code en plein cycle. Je commence à le décomposer de plus en plus sans revenir me préoccuper de l’étape du cycle.
Ce qui fait que je me retrouve souvent avec un code beaucoup plus avancé par rapport au test dont certaines parties ne sont pas testées.
Et là, pas le choix de devoir tester du code que j’ai produit en plus, ce qui va à l’encontre de la méthode.
Comment résoudre cette erreur?
Il n’y a pas de recette miracle dans ce cas de figure.
Il n’y a que 2 choses à faire : accepter de faire l’erreur et continuer de pratiquer la méthode pour ne plus la faire et rendre la méthode naturelle.
Car il faut être honnête, il est plus naturel de coder puis de tester plutôt que l’inverse. Donc, il est normal de ne pas maîtriser et ne pas réussir à mettre en application directement une nouvelle façon de faire.
À quel moment peut-on appliquer la méthode?
Si vous avez suivi jusqu’ici, vous avez compris que l’on ne peut pas appliquer cette méthode quand on le souhaite. Le plus judicieux serait de le faire au début d’un nouveau projet et de l’appliquer comme la norme pour tous les développeurs qui travailleront sur le projet.
Mais vous pouvez l’expérimenter sur de nouvelles fonctionnalités, ce qui sera plus facile et moins lourd à supporter.
Et pour l’existant?
Pour l’existant, c’est plus compliqué puisque le code existe déjà (et peut-être même les tests). Vous ne pouvez pas appliquer la méthode TDD puisque ce sont les tests qui pilotent le code.
Cependant, vous pouvez le faire tout de même sur des fonctionnalités que vous devez corriger ou améliorer. Vous devez alors vous faire violence en partant du principe que vous allez refactoriser complètement la fonctionnalité.
Suivant le contexte de votre projet et la criticité de la fonctionnalité, cela ne sera peut-être pas le plus judicieux.
Épilogue
Voilà maintenant quelque temps que j’expérimente cette manière de produire des applications. Je trouve que c’est particulièrement efficace en termes de production de code de qualité et surtout de santé mentale.
Cela m’enlève un stress et un poids énorme, car je sais que chaque partie de mon application est testée.
Mais avouons-le, la méthode sur le principe n’est pas très alléchante, car quel est le développeur qui aime vraiment faire des tests ? Si vous êtes comme moi, vous préférez coder une application plutôt que d’écrire des tests pour la tester.
Dites-vous bien que si vous souhaitez vous améliorer continuellement et devenir de plus en plus efficace, vous devrez forcément passer par ce cap.
Je ne peux que vous dire qu’essayer la méthode TDD, c’est l’adopter, même si dans mon cas, je suis encore dans l’étape de la dompter.
Si vous voulez voir la méthode TDD en pratique et en vidéo, vous pouvez cliquer ici.
