Introduction

Cet article fait suite à celui intitulé TDD, ce n'est pas ce que vous croyez... dans lequel j'expliquais que notre vision de TDD était la plupart du temps erronée. Et ce manque de compréhension a souvent entrainé l'abandon pur et simple de la méthode à cause d'un excès de temps perdu et de code écrit en trop grande quantité.

Et pourtant, en utilisant correctement TDD, c'est l'inverse qui devrait se produire. Bien que l'écriture des tests implique du code supplémentaire (pour ceux qui ne suivent pas, les tests, c'est du code), la finalité de cette méthode est de vous permettre d'écrire le code nécessaire à la mise en place de vos fonctionnalités, ni plus, ni moins. Et ça, c'est un gain de temps énorme. Le code mort et le PNG (prévu non géré), on le met à la poubelle.

Deuxième gain de temps, vous passerez moins de temps avec le debugger. Et ça, ça n'a pas de prix !

Article connexe TDD n'est pas ce que tu crois

Les étapes dans la pratique de TDD

Lorsque vous lirez un article sur TDD, vous verrez apparaître le fameux cycle :

  • Red
  • Green
  • Refactoring

C'est là toute l'essence de TDD. C'est d'une simplicité et d'une force à toute épreuve.

Red - Le test ne passe pas

Dans la plupart des outils de tests unitaires, la couleur rouge marque l'échec d'un test. Et l'échec d'un test, c'est une mauvaise chose. Et cette règle ne change pas avec TDD.

Mais avec TDD, cette couleur rouge peut signifier une seconde chose : la naissance d'un nouveau test.

On peut d'ailleurs faire l'analogie du test rouge avec les pleurs d'un bébé. A la naissance, ce dernier pleure par réflexe et s'il pleure, c'est que tout va bien. S'il ne pleure pas, les médecins vont devoir vérifier manuellement que le bébé soit fonctionnel en bonne santé.

Par la suite, à chaque fois que le bébé pleurera, cela signifiera au contraire qu'il y a un problème et qu'il a besoin qu'on le règle.

Et bien, avec TDD, c'est pareil. Le rouge permet de savoir que le test est en place et qu'il est prêt à pleurer fonctionner en cas de problème. S'il ne devient pas rouge (cela peut arriver), il vous faudra vérifier manuellement qu'il est prêt à remplir son rôle.

Par la suite, à chaque fois qu'il deviendra rouge, cela signifiera au contraire qu'il a rencontré une anomalie et qu'il a besoin qu'on la corrige.

Le premier passage au rouge est une étape très importante. Ne l'ignorez jamais !

Green - Le test passe

Une fois qu'on sait que le test est en bonne santé, il va falloir le faire passer au vert. Et le vert, dans les outils de tests unitaires, cela veut dire que tout est OK.

Avec TDD, il faut faire en sorte de faire passer le test au vert le plus rapidement et le plus simplement possible.

Et s'il le faut, vous pouvez même tricher. Par exemple, si vous travaillez sur une fonction qui doit renvoyer une valeur, vous pouvez directement renvoyer la valeur voulue.

L'objectif, c'est que le test passe au vert de la manière la plus simple qui soit et avec le moins de code possible !

Refactoring - La quintessence de l'art du développeur

Et nous voilà dans la phase la plus intéressante (à mon goût) de TDD, le refactoring.

C'est dans cette étape que vous pouvez montrer que vous êtes un vrai développeur. Vous pouvez faire ce que vous voulez, vous avez un filet de sécurité : tous les tests doivent rester vert.

Le premier objectif de cette étape est de supprimer les éventuelles tricheries que vous avez ajoutées à l'étape précédente. Vous devez les faire disparaître du code tout en veillant à ce que tous les tests restent verts.

Le second objectif est de pratiquer la règle du boy-scout. Le code doit être plus propre après votre passage. Pour cela, plusieurs possibilités :

  • vous devez supprimer tout le code mort possible ;
  • vous pouvez renommer les variables et autres éléments de programmation.

Ça reste vert ? Alors, tout est OK.

Le troisième objectif est le plus important. Vous pouvez factoriser votre code. A ce stade, vous devez respecter toutes les règles de programmation que vous connaissez (SOLID, DRY, etc...) et vous devez mettre en place l'architecture de votre code (par exemple, l'architecture hexagonale ou la clean architecture).

Ça reste vert ? Alors, vous avez réussi !

Vous pouvez retourner à l'étape du red !

La granularité des tests

Lorsqu'on pratique TDD, il faut faire attention aux tests que l'on met en place. Il ne faut surtout pas passer du coq à l'âne. Chaque test est un petit pas vers la solution finale et essayer d'aller trop vite, c'est le meilleur moyen de se perdre.

Pour vous donner une idée de la granularité des tests, voici un kata (exercice de programmation) que j'ai pratiqué : créer une calculatrice. On donne une expression et l'ordinateur doit nous donner le résultat. Elle doit gérer les parenthèses et les 4 opérations.

Notez que je n'ai pas utilisé de fonctions WinDev qui retourne directement le résultat. Les seules fonctions que j'ai utilisées pour résoudre ce problème sont : Position, NumériqueVersChaine et Val.

Vous trouverez à la fin de l'article les tests que j'ai utilisés (les uns après les autres) pour mettre en place mon algorithme de calcul. Vous pouvez les réutiliser ou définir les vôtres.

N'hésitez pas à me faire parvenir vos résultats. Et moi, je vous livrerai ce que j'ai fait dans un prochain article.

Conclusion

Nous avons vu que TDD suit les étapes suivantes Red - Green - Refactoring. En effectuant ce cycle un pas après l'autre, nous nous équipons d'un outil qui facilite la création de programme de plus en plus complexe.

Nous verrons dans les articles suivants les choses que l'on ne doit pas faire en TDD, l'importance de choisir une architecture adaptée et la notion de BDD (Behaviour Driven Development) qui, couplée avec TDD, rend magique le développement d'application.

Je vais aussi sortir un composant qui modifiera complètement votre approche des tests unitaires et qui vous donnera envie d'aller plus loin dans cette démarche.

J'essaierai aussi de publier des vidéos qui complèteront mes explications.

J'espère que vous avez pris plaisir à lire mon article. Je sais que la méthode TDD paraît compliquée et difficile à mettre en œuvre, mais si vous arrivez à suivre cette voie, je vous garantis de révolutionner votre vision du développement de logiciel.

N'hésitez pas à partager cet article sur les réseaux sociaux et surtout laissez des commentaires, que ce soit pour me dire que je me trompe, dire que vous avez apprécié l'article ou pour poser des questions.

Et si vous souhaitez aller plus loin, rejoignez moi sur le slack wx-community, un channel #tdd y a été ouvert.

Je vous remercie de m'avoir lu et je vous souhaite une bonne journée.

Les tests du kata Calculatrice :

| commentaire                          | entrée         | résultat
|--------------------------------------|----------------|---------
| 0 doit donner 0                      | 0              | 0
| 1 doit donner 1                      | 1              | 1
| 2 doit donner 2                      | 2              | 2
| 1+1 doit donner 2                    | 1+1            | 2
| 1+2 doit donner 3                    | 1+2            | 3
| 2+2 doit donner 4                    | 2+2            | 4
| 2*3 doit donner 6                    | 2*3            | 6
| 3*3 doit donner 9                    | 3*3            | 9
| 10/2 doit donner 5                   | 10/2           | 5
| 1+1+1 doit donner 3                  | 1+1+1          | 3
| 1+1+2 doit donner 4                  | 1+1+2          | 4
| 10+11+12 doit donner 33              | 10+11+12       | 33
| 2+3*6 doit donner 20                 | 2+3*6          | 20
| 2*3+6 doit donner 12                 | 2*3+6          | 12
| 5-3 doit donner 2                    | 5-3            | 2
| 5-5 doit donner 0                    | 5-5            | 0
| 2*3-5 doit donner 1                  | 2*3-5          | 1
| 1+2+3+4 doit donner 10               | 1+2+3+4        | 10
| 5-6 doit donner -1                   | 5-6            | -1
| 5-6*2 doit donner -7                 | 5-6*2          | -7
| 10-5-5 doit donner 0                 | 10-5-5         | 0
| (0) doit donner 0                    | (0)            | 0
| (1) doit donner 1                    | (1)            | 1
| (10) doit donner 10                  | (10)           | 10
| (1+1) doit donner 2                  | (1+1)          | 2
| (1)+1 doit donner 2                  | (1)+1          | 2
| (1)+(1) doit donner 2                | (1)+(1)        | 2
| (1+1)+(1+1) doit donner 4            | (1+1)+(1+1)    | 4
| (2+3)*(4+6) doit donner 50           | (2+3)*(4+6)    | 50
| 5.2+3.8 doit donner 9                | 5.2+3.8        | 9
| 1.234*5.6789 doit donner 7.0077626   | 1.234*5.6789   | 7.0077626