Introduction

Le Test Driven Development, une philosophie du développement

Le TDD est une philosophie qui défie le développement traditionnel : d’abord tester, ensuite coder et finalement refactoriser. C’est une technique qui est devenue populaire en favorisant le développement de code plus propre et plus flexible.

A propos de l’auteure

Florence est développeuse Java, consultante pour Diggers depuis 2020. Passionnée par son métier, elle est une adepte des bonnes pratiques de développement et perpétuellement à la recherche d’axes d’amélioration. Convaincue de l’intérêt du TDD, elle anime des ateliers de coaching au sein de Diggers, mais également au sein des équipes client chez qui elle intervient. Elle est reconnue pour son professionnalisme, la qualité du code qu’elle délivre, mais également pour son formidable esprit d’équipe et sa capacité naturelle à fédérer !

Bien tester votre application, c’est l’assurance que votre code fonctionne comme prévu!

Malgré son importance, il n’est pas rare de trouver des équipes qui ne testent pas de manière systématique, ce qui conduit à des bugs, des comportements inattendus et un manque de fiabilité. Afin d’augmenter la qualité de votre projet, nous verrons comment intégrer le TDD dans votre quotidien.

Il est important de souligner qu’il existe différentes méthodologies de test. Dans cet article, je m’emploierai à détailler l’approche du TDD, mais ces propositions peuvent être répliquées de manière générale à d’autres types d’approches.

Mais pourquoi tester mon application en utilisant l’approche du Test Driven Development?

Avant d’utiliser TDD, nous devons d’abord nous assurer que nous comprenons les avantages et les bénéfices qu’une équipe de développement peut retirer d’une méthodologie de test correctement déployée et industrialisée.

Parce que les tests permettent de documenter votre code

Les tests effectuent la fonction de la documentation de votre produit. Chacun des tests représente une règle sur la façon dont votre code doit (ou ne doit pas) se comporter. C’est l’équivalent d’avoir une longue liste de règles métier, mais qui sont automatiquement auditables. C’est-à-dire, en cliquant sur un bouton, vous pouvez vérifier que votre système fonctionne comme prévu. Couplé à un système de versionning (ex. Git) il est possible de voir tout l’historique des décisions fonctionnelles et techniques.

Comme pour toute documentation, un travail actif est nécessaire pour la maintenir à jour. Lorsqu’une nouvelle demande fonctionnelle apparaît, un test qui décrit le nouveau fonctionnement est créé, les anciens tests ainsi que le code sont adaptés pour refléter le nouveau comportement, et ainsi nous avons la documentation et le code à jour.

Parce que les tests servent de support de transfert de connaissances

Personne ne connaît à 100% le code d’un projet, ni même ceux · celles qui ont des années d’expérience dans l’équipe. Au fil du temps, inévitablement, les raisons pour lesquelles les décisions ont été prises commencent à être oubliées, et nous sommes alors confrontés à un code dont nous ne savons pas pourquoi il fonctionne comme tel. Ce problème devient encore plus latent avec le turn-over, où des personnes connaissant l’historique du projet partent et de nouvelles personnes ne connaissant pas les règles obscures du code arrivent.

Comme nous l’avons vu, les tests servent de documentation. Ainsi, pour vous familiariser avec un extrait de code, vous pouvez accéder à tous les tests qui passent par cet extrait, trouvant ainsi facilement les scénarios qui conduisent à ce comportement (ce qui est plus rapide que de lire toute la documentation de façon conventionnelle).

Aussi, il est toujours intéressant d’écrire de nouveaux tests pour voir comment le code réagit. C’est un moyen instantané de tester des hypothèses et de vérifier que le comportement est comme prévu.

En résumé, combiner la lecture de tests existants avec l’exploration de nouveaux scénarios permet à différentes personnes de travailler plus facilement avec le même code.

Parce que les tests évitent les régressions

Nous avons tous vécu l’expérience terrifiante de modifier une ligne de code sans être sûr·e·s que tout le restant reste intact. Les tests sont votre garantie que le code fonctionnera : si vous modifiez quelque chose de manière inappropriée, nous savons qu’un test vous montrera automatiquement que cette modification n’aurait pas dû être effectuée. Avec cette garantie, vous devenez plus confiant pour apporter des modifications.

Dans le cadre où les tests n’existent pas, vous n’êtes pas tout à fait sûr qu’une modification se fera sans effets secondaires. Ne sachant pas s’il y a des effets secondaires, vous avez plus peur d’améliorer le code. En conséquence, de plus en plus le code aura des duplications, des effets secondaires et comportements inattendus.

En bref, négliger les tester conduit à du mauvais code

Ok, tu m’as convaincu(e)! Par où commencer?

Une fois que vous avez compris les avantages des tests, nous pouvons commencer à pratiquer le TDD.

Je suggère de commencer par apprendre les bases du TDD puis de les appliquer à un vrai projet. Dans un premier temps, l’idée d’apprendre le TDD directement avec un projet semble intéressante. C’est-à-dire, avec l’objectif d’apprendre la méthodologie tout en ajoutant de la valeur au business.

Cependant, ce choix entraîne une surcharge mentale : en général, les user stories ne sont pas simples comme « 1 + 1 doit renvoyer 2 », plusieurs scénarios et règles sont utilisés pour composer une user story. Et même s’il est facile à comprendre, des aspects tels que l’architecture, la latence, l’expérience utilisateur doivent être pris en compte lors de la prise de décision pour une bonne solution.

L’apprentissage implique le concept de faire des erreurs, il est donc préférable d’apprendre au moins les bases du TDD dans un environnement sûr et isolé des impacts clients. Ma suggestion est de créer un projet à partir de zéro et de mettre en pratique des exercices conçus pour TDD.

Un bon exemple est le kata. Un site de référence est https://kata-log.rocks/starter . Vous pouvez y trouver plusieurs exercices pour entraîner vos concepts TDD. Ces exercices peuvent être effectués individuellement ou en groupe avec d’autres développeurs. Lorsque nous réalisons l’activité en groupe, nous avons l’avantage de partager des connaissances avec les autres, en plus de pouvoir changer nos façons de coder biaisés, ce qui est toujours une expérience enrichissante. Cependant, des problèmes tels que la disponibilité et les deadlines peuvent rendre ces moments de partage difficiles. Ainsi, effectuer les exercices individuellement apporte également un grand apprentissage et nous familiarise avec les concepts.

Quoi qu’il en soit, sur Internet, nous avons des vidéos de personnes qui effectuent les exercices proposés, ce qui nous aide à avoir un point de vue différent, même lorsque nous pratiquons seul.

Conclusions

Le TDD peut apporter plusieurs avantages, mais comme toute technique, il faut savoir s’en servir. Commencez par des exercices conçus pour l’apprentissage puis évoluez vers de vrais projets. En utilisant des stratégies telles que le Pair Programming et le Mob Programming, il est possible de réunir toute l’équipe de développeurs pour apprendre ensemble.

J’espère vous avoir aidé et encouragé à tester ! Bon courage ! 😊

Article précédent

Article suivant