Méthodologie

Test Driven Development ou comment piloter son code par les tests

Test Driven Development ou comment piloter son code par les tests

Je vous ai parlé il y a quelque temps de ce qu’étaient les tests unitaires en vous expliquant leur importance et une stratégie à adopter pour pouvoir en faire. Si vous avez commencé à en faire ou même si vous avez essayé alors dîtes-vous bien que vous avez déjà fait un grand pas en avant, car pour rappel j’ai mis 10 ans à m’y mettre.

Écrire des tests unitaires est donc déjà une bonne chose et je vous ai expliqué comment écrire des tests pour du code DÉJÀ produit. Et c’est peut-être la seule manière de faire à vos yeux pour le moment.

Pourtant il existe une autre méthode de faire des tests qui est non seulement plus efficaces, mais surtout très différents de ce que vous avez pu voir jusqu’à présent.

Si vous comprenez cette méthode et que vous la mettez en application, cela va changer fondamentalement votre manière de programmer, mais surtout la qualité du code que vous produirez à l’avenir.

commitstrip-parse-error

Source : https://www.commitstrip.com/fr/2013/02/01/combien-de-temps-peux-tu-coder-sans-tester/

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éveloppements pilotés 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 coeur 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 coeur 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 de cycle. Et pour chacun des cycles que vous pouvez être amené à réaliser, il y a 3 étapes à réaliser :

Test driven development

Il y a 3 étapes à réaliser :

  1. 1er étape : écrire un test qui échoue
  2. 2ème étape : faire en sorte que votre test passe
  3. 3ème étape : retravailler le code produit

Et ainsi de suite ! Le but de réaliser ces étapes sur des parties très courtes pour former beaucoup de cycles pour la réalisation d’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 pour gérer les tags d’une application.

1er étape : écrire un test qui échoue

Il faut donc commencer par écrire votre test. N’oubliez pas que la méthode veut que vous avanciez par petit pas. Il faut donc aller au plus simple. Ici on doit dans l’exemple juste 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 tests :

Tdd step 1 example

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 :

Tdd step 2 example

Une fois implémenté, on relance tout simplement notre test pour constater que celui-ci 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é ? Non pas vraiment étant donné que nous avons uniquement implémenté une méthode sans écrire des choses dedans. Donc pas de refacto pour cet exemple.

Les prochains cycles par rapport à l’exemple

Je vous ai montré l’exemple d’un cycle où 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é réaliser.

On pourra faire par exemple un cycle pour implémenter des variables d’entrées à la méthode. Puis un autre pour traiter ses données d’entrée, puis l’enregistrement des informations pour obtenir une création, etc.

Vous comprenez le principe ? Vous allez découper par petit bout le travail du code que vous avez l’habitude de produire, mais en commencer 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 plus qualitatif.
  • 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)
  • On réfléchit beaucoup plus métier que technique ce qui améliore fortement la qualité de l’application d’un point de vue fonctionnelle
  • Vous n’allez finalement tester que ce qui doit être réellement testé.

L’erreur que vous allez très certainement faire (et c’est normal)

Comme je vous dis dernièrement, 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 allez certainement faire aussi 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 dîtes comment ? Et bien dans mon cas ce sera à 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 à 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 naturelle 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.

A 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 c’est les tests qui pilotent le code.

Cependant, vous pouvez le faire tout 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 refactorer 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.

Epilogue

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.

Dîtes-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 🙃.

Partager ce contenu
  • 4
    Partages

Leave a Comment

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.