Le développement de logiciels repose sur plusieurs étapes caractérisées par le PDCA ou Plan - Do - Check - Act. Or, l’une des étapes les plus importantes de la roue de Deming, c’est justement la phase de vérification (ou test). Pour cela, il existe différentes méthodes capables de contrôler la qualité et la fiabilité des logiciels. Parmi lesquels, le Test Driven Development. Alors de quoi s’agit-il ? Quels sont les avantages et inconvénients de cette méthode ? Et surtout, comment la mettre en place ? DataScientest répond à toutes vos questions.
Qu’est-ce que le Test Driven Development ?
Définition du TDD
Le Test Driven Development (ou développement piloté par les tests en français) est une méthodologie de développement logiciel répondant à une politique de test first. L’idée est alors de guider la programmation de software ou d’application à travers une série de tests. Et ce, avant même de commencer à écrire le code.
Ainsi, dès qu’ils rencontrent des bugs, les développeurs les corrigent au fur et à mesure. Le fait de réaliser des tests régulièrement permet d’éliminer rapidement (presque en temps réel) toutes les anomalies détectées dans le code source. À ce titre, le TDD répond parfaitement aux exigences de la méthode Agile, puisqu’il implique d’avancer par itération pour améliorer le logiciel progressivement.
Bon à savoir : Cette approche a été initiée par le développeur américain Kent Beck. Il a simplement inversé le processus utilisé, en commençant par écrire le test avant d’écrire le code. Ce qui lui permet d’améliorer la qualité du code.
TDD et autres procédures de test
Si le Test Driven Development est une méthode très connue des DevOps, c’est loin d’être la seule méthode de vérification de la qualité des logiciels :
- L’acceptance Test Driven Development (ou ATDD) : c’est une méthode complémentaire au TDD. Dans ce cas, les développeurs s’attachent surtout à vérifier la cohérence d’un scénario applicatif avec les objectifs visés. Cette approche est centrée sur les tests d’application fonctionnelle.
- Le Behavior driven development : également appelé programmation pilotée par le comportement, le BDD focalise son attention sur le comportement souhaité, et non pas sur l’exactitude du code.
- Le Domain Driven Design (DDD) : il s’agit surtout de définir une vision et un langage communs à toutes les parties prenantes.
Toutes ces méthodes sont complémentaires. Ensemble, elles permettent de concevoir un logiciel de meilleure qualité, évolutif et fiable, tout en réduisant la dette technique.
Quels sont les avantages et inconvénients du TDD ?
Avantages
Aujourd’hui, le Test Driven Development est préconisé pour la majorité des processus de programmation. Et pour cause, cette méthode de vérification permet d’en retirer une multitude de bénéfices :
- Anticiper la faisabilité du logiciel : en écrivant les tests avant même d’écrire le code, les développeurs s’assurent que la conception même du logiciel permet d’atteindre les objectifs. En effet, les tests répondent davantage aux besoins métiers. Et surtout, les DevOps sont capables de couvrir davantage de tests unitaires.
- Gagner du temps : ce travail d’écriture du test en amont évite également de perdre du temps à développer des fonctionnalités ne répondant pas aux objectifs visés.
- Minimiser les erreurs : le développement étant piloté par les tests, les développeurs peuvent détecter les bugs presque en temps réel. Ce qui limite les erreurs post-déploiement.
- Simplifier la maintenance : corollaire du point précédent, la réduction des bugs permet aussi de gagner du temps en termes de maintenance et de surintendance.
Inconvénients
Malgré tous les avantages du Test Driven Development, il convient aussi d’être conscient de ses limites.
D’une part, cette procédure de vérification implique une compréhension exhaustive du code. Ce qui implique un temps de formation plus long avant de commencer à écrire ledit code.
D’autre part, l’objectif du déploiement piloté par les tests est surtout de vérifier l’exactitude du code. Cette méthodologie ne s’attarde pas à contrôler l’utilisation du logiciel et de ses fonctionnalités. C’est pourquoi, le TDD doit généralement être complété par d’autres procédures de test (notamment le BDT).
Quelles sont les 3 phases du développement piloté par les tests ?
Le Test Driven Development repose sur 3 lois fondamentales, à savoir :
- « Vous devez écrire un test qui échoue avant de pouvoir écrire le code de production correspondant »
- « Vous devez écrire une seule assertion à la fois, qui fait échouer le test ou qui échoue à la compilation »
- « Vous devez écrire le minimum de code de production pour que l’assertion du test en échec soit satisfaite ».
Mis bout à bout en une seule itération, ces 3 lois constituent un nano-cycle de TDD. Traditionnellement, elles se schématisent à travers un cycle en 3 phases : red (rouge), green (vert) et refactor (remaniement).
Phase Red
Première étape du Test Driven Development, le développeur doit décrire un problème à travers l’écriture d’un test unitaire. Mais comme le code n’existe pas encore, le test est voué à échouer lors de son exécution. D’où le symbole de la couleur rouge.
Afin de réaliser ce test, le développeur se met à la place de l’utilisateur final en décrivant les composants manquants indispensables au fonctionnement du code. Mais il s’agit là de composants n’ayant pas encore été implémentés.
Phase Green
L’objectif de cette phase est de réussir le test. Pour cela, le développeur écrit un morceau de code en complétant le test unitaire rédigé en amont. Il doit passer au vert. C’est donc une phase de recherche où le développeur doit trouver une solution à la problématique posée.
Mais attention, au cours de cette phase du Test Driven Development, le DevOps ne doit pas rechercher de solution complexe. Il doit se focaliser sur l’essentiel pour que le code de production passe au vert. Il vérifie alors la réussite du code en exécutant d’autres tests.
Phase refactor
Ce n’est qu’après avoir trouvé la solution que le développeur peut passer à l’étape du refactoring. Il peut alors remanier le code, le structurer, le rendre plus lisible et éventuellement le compléter. Pour autant, il ne doit pas modifier les comportements du code. C’est-à-dire qu’il doit conserver chaque fonctionnalité. Là encore, il doit vérifier que chaque test soit validé à chaque ajout d’une nouvelle fonctionnalité.
