TDD...

Vous avez certainement déjà entendu ce terme. Peut-être l'utilisez-vous dans vos projets ? Si c'est le cas, bravo ! Car la plupart des projets WinDev® n'en font pas usage.

On nous avait vendu TDD comme la solution miracle pour avoir un projet entièrement testé. Cette solution devait nous faciliter le code... mais les faits sont là, les rares qui ont essayés se sont cassés les dents ou y ont passé un temps monstrueux dessus, avant d'abandonner...

Je le sais, j'ai essayé... puis j'ai abandonné, puis j'ai essayé à nouveau... et puis, plus rien...

Voilà le bilan de TDD aujourd'hui. Une superbe philosophie sur laquelle nous nous cassons les dents. Dure à utiliser et chronophage à souhait.

C'est quoi TDD ? L'idée reçue

Pour ceux qui ne connaissent pas, TDD signifie Test Driven Development ou en français Développement Dirigé par les Test. C'est une méthode de développement qui commence à avoir quelques années derrière elle.

La philosophie derrière TDD est d'utiliser les tests unitaires pour vous aider à coder votre projet.

Et qu'est-ce qu'un test unitaire ? C'est un bout de code que l'on peut facilement lancer à volonté pour vérifier qu'un autre bout de code fonctionne comme on l'attend. WinDev permet de créer ces tests unitaires et de les lancer à volonté.

Ce que n'est pas TDD

Entrons directement dans le vif du sujet. Bien que l'on pense le contraire, la plupart d'entre nous ne savons pas ce qu'est réellement TDD. Je pensais avoir compris le principe depuis plusieurs années, mais en fait, cela fait seulement quelques semaines que j'ai commencé à comprendre le fonctionnement. Et je suis toujours en apprentissage.

Merci Michael de m'avoir sorti de l'ignorance !

TDD, ce n'est pas un test unitaire par méthode

TDD, contrairement à ce que l'on pense, ce n'est pas un test unitaire par méthode. Ce n'est pas une collection de tests par classe. Il faut oublier cela. C'est cette croyance qui nous fait casser les dents sur TDD.

Pourquoi ?

Tout simplement que notre code évolue à force de faire du refactoring. Si l'on teste toutes les méthodes, on va forcément casser nos tests à chaque modification de code. Les tests doivent permettre le refactoring, pas le figer.

Le terme unitaire dans test unitaire signifie simplement que n'importe quel test doit pouvoir fonctionner de manière indépendante des autres tests. Un test ne doit surtout pas avoir une influence quelconque sur le résultat d'un autre test. On pourrait remplacer le terme unitaire par isolé.

TDD, ce n'est pas une source de lenteur dans le développement.

Un test doit répondre à plusieurs critères (que nous verrons plus tard) et la lenteur n'en fait par partie. Si vos tests sont lents, c'est qu'il y a un problème dans votre code ou dans vos tests.

Au contraire, une bonne utilisation de TDD vous permettra d'accélérer vos développements :

• TDD vous aide à avoir un code propre et bien organisé ;
• l'ajout de nouvelles fonctionnalités sur un projet énorme sera simplifié, ce qui signifie encore du temps gagné ;
• même si l'idée principale n'est pas de tester le code, vous aurez tout de même des tests qui protégeront votre code des régression et des bugs ;
• enfin, TDD vous aidera à mettre en place une architecture qui facilite la réutilisabilité de votre code.

Que du temps gagné.

TDD, ce n'est pas du Test First Development

Quand vous et moi avons pensé apprendre TDD, nous avons appris le Test First Developpment. Les deux sont proches dans l'idée (test unitaire, anti-régression, toussa), sauf que l'objectif de TDD est de vous donner une direction. Avec TFD, vous avez directement créé la classe et la méthode qui répondent au test, tandis qu'avec TDD, vous allez faire émerger le code qui va répondre au test, et ce code qui émerge sera probablement différent du code que vous aurez pondu dans le cas de TFD.

Mais si vous faîtes du TFD, alors, c'est déjà une bonne chose.

Article connexe : The difference between TDD and Test First Development

Mais alors, c'est quoi TDD ?

TDD, c'est toute une méthodologie que nous allons découvrir ensemble au sein d'une multitude d'articles (si j'ai le courage de les écrire) mais pour faire bref, TDD vous permet de découvrir le design de votre code et de coder vos fonctionnalités pas à pas.

Avant de conclure, j'aimerai tout de même vous dire les avantages et inconvénient que je trouve à TDD.

Les inconvénients

• Il devient très difficile de travailler sur du code legacy. Le code legacy, c'est celui d'un vieux projet qui n'est pas couvert par les tests et que vous n'avez pas développé.
• Votre pique de stress augmente quand vous ne travaillez plus avec les tests.
• Vous risquez de tomber en désaccord avec vos collègues et vos supérieurs hiérarchiques s'ils n'adhèrent pas à la philosophie TDD.

Bref, TDD est l'une des raisons pour lesquels j'ai décidé de quitter le salariat pour me mettre à mon compte.

Les avantages

• Vous êtes guidés en permanence par les tests, vous n'aurez plus peur de vous perdre.
• On teste son code très rapidement et très simplement. Pas besoin de manipuler la souris ou le clavier pour voir si tout fonctionne.
• On a un code beaucoup plus élégant.
• Les tests sont une véritable documentation de votre code et de votre projet.

Conclusion

Nous n'avons pas encore vu ce qu'est réellement TDD, mais j'espère vous avoir donné envie de poursuivre l'aventure avec moi. J'ai encore beaucoup de choses à vous apprendre et à apprendre moi-même.

Mais une chose est sûre, la méthodologie TDD ne correspond pas à ce que la majorité des développeurs croient et si vous l'utilisez pas déjà, elle vous sera très bénéfique.

N'hésitez pas à me donner votre opinion ou à me corriger. En effet, il n'y a pas une mais mille manières de faire. J'essaierai de vous enseigner ma vision des choses, mais je compte sur vous pour vous faire votre propre idée.

Merci d'avoir pris le temps de me lire.

Et merci à Mickael pour la relecture et les suggestions.