Je sais que la méthodologie TDD a fait l'objet d'un grand battage médiatique ces dernières années, et je comprends le scepticisme que vous pouvez avoir à l'égard des projets logiciels qui font l'objet d'une grande attention. Cependant, je peux vous dire par expérience que le TDD n'est pas qu'une mode. Avant les tests unitaires, j'ai développé de nombreux logiciels que je considérais comme "solides comme le roc" (pas de bogues, excellentes performances, etc.). J'ai entendu parler des tests unitaires et j'ai décidé de les essayer sur un "petit projet", d'autant plus que leur mise en œuvre ne prendrait pas beaucoup de temps.
À ma grande surprise, j'ai rapidement compris l'intérêt des tests. Des fonctions que je croyais parfaites à 100 % produisaient des résultats étranges. La modification d'un composant pouvait faire échouer le test unitaire d'un autre. C'était intéressant parce que je me suis rendu compte que mon code ne fonctionnait que lorsque j'entrais ce que j'attendais (en tant que développeur) d'un utilisateur, et non ce qu'il pourrait réellement faire dans la version de production de l'application.
Cette surprise m'a conduit à un certain nombre de conclusions sur la TDD (en dehors des avantages habituels) :
- Le TDD vous permet de tester chaque composant à n'importe quel stade de l'application (vous pouvez configurer l'environnement pour chaque test). Cela vous permet de vous assurer que la fonctionnalité d'un composant reste uniforme dans toute l'application.
- Le TDD encourage généralement une bonne conception. Il est généralement impossible de tester les unités individuelles d'une application sans "décomposer" le système. La décomposition de l'application en parties testables (en particulier lorsque vous utilisez le modèle d'inversion de contrôle) oblige le développeur à écrire un meilleur code.
- Le TDD renforce la confiance du développeur et de l'utilisateur final dans un système. Feriez-vous confiance à un système qui n'est pas testable ? Ou à un système qui a été testé en profondeur ?
Le TDD présente de nombreux autres avantages. Il y a aussi des inconvénients (temps de mise en œuvre, mise en œuvre incorrecte des tests). Ce que je peux dire, c'est que la pratique du TDD vous aidera généralement à améliorer vos compétences en matière de développement.
Enfin, je sais que vous avez mentionné que vos projets ont tendance à être petits, alors ma question est la suivante : pourquoi ne pas tester ? La mise en œuvre ne sera pas si longue. Si vous développez en .NET et en Java, les principaux IDE disposent de fonctions permettant de rationaliser le processus de test. Je suis également prêt à parier que d'autres langages disposent de fonctionnalités similaires dans leurs IDE.
