Test-Driven Development garantit la qualité du code en développement logiciel. Le code est non seulement fonctionnel, mais aussi optimisé pour être capable de durer et d'évoluer dans le temps.
Qu'est-ce que Test-Driven Development ?
Test-Driven Development est une méthode de développement logiciel piloté par les tests : on écrit le test avant d'écrire le code, on teste chaque portion de code avant d'écrire la suivante, et on améliore le code en continu. Agilité, itérations et granularité caractérisent TDD.
Qui a inventé TDD ?
L'invention de TDD n'est pas attribuée, mais le mérite de sa popularisation revient à l'informaticien américain Kent Beck. Il l'affirme lui-même : « I refer to my role as “rediscovering” TDD », une méthode visiblement évidente pour l'ancienne génération de développeurs.
- 1999 : Kent Beck exprime l'idée de TDD dans son ouvrage Extreme Programming Explained, en en faisant une des pratiques de l'eXtreme Programming. À ce moment-là, TDD est compris comme du simple test-first : on écrit le test unitaire avant d'écrire la portion de code correspondante.
- 2005 - 2008 : l'ingénieur américain Robert Cecil Martin, surnommé Uncle Bob, a échangé avec Kent Beck pour affiner sa compréhension de TDD. Il a compris que TDD était plus que du test-first : le processus de test se fait ligne de code par ligne de code, au niveau de granularité – le plus haut niveau de détail. On écrit le test qui échoue, puis on écrit le code de production correspondant. Robert C. Martin tente d'en rendre compte en écrivant 3 lois de TDD. Différentes formulations similaires des lois se succèdent.
- 2014 : le terme « unitaire » disparaît des 3 lois de TDD, pour mieux rendre compte du niveau de granularité des tests.
Pourquoi faire du TDD ?
- Faciliter le débogage
- Faire efficace et simple
- Faire preuve de professionnalisme
Faciliter le débogage
Test-Driven Development impose de tester chaque ligne de code, l'une après l'autre, et surtout de ne pas écrire la ligne suivante avant d'avoir validé la précédente. Si un test échoue, il n'y a donc pas besoin de revenir loin en arrière : l'erreur dans le code est identifiée et corrigée immédiatement. Cela facilite considérablement le débogage.
Faire efficace et simple
Le processus itératif de Test-Driven Development exige de tester et valider le comportement du code, puis de le remanier en continu. Cela pose une discipline : le développeur s'assure que le code fonctionne, puis il travaille à l'optimiser. Se concentrer sur le fonctionnement du code, et seulement après sur sa structure, est plus efficient que de travailler simultanément les deux aspects – selon Robert C. Martin.
Faire preuve de professionnalisme
« Test-driven development is a discipline that helps professional software developers ship clean, flexible code that works, on time. » Pour Robert C. Martin, appliquer la méthode Test-Driven Development est une preuve de professionnalisme, car les tests sont poussés au plus haut niveau de détails. Le développeur est sûr du code qu'il livre, puisqu'il a été entièrement testé, avec la plus grande précision, plusieurs fois. C'est un gage de confiance pour les clients.
Quelles sont les étapes pour faire du Test-Driven Development ?
- Écrire un test qui échoue (Red).
- Écrire le code de production pour passer le test (Green).
- Remanier le code (Refactor).
1 - Écrire un test qui échoue (Red)
La première étape de la méthode Test-Driven Development , intitulée Red, consiste à écrire le test avant d'écrire le code de production correspondant. Ce test échoue nécessairement puisque le code à tester n'existe pas encore.
Écrire et exécuter le test avant d'écrire le code à tester offre un intérêt certain : tout le code est testable, ce qui limite le risque de bugs. L'écriture préalable du test, par ailleurs, aide à mieux comprendre le besoin, pour écrire du code utile et précis.
2 - Écrire le code de production pour passer le test (Green)
L'idée de cette seconde étape, intitulée Green, est de passer le test avec le minimum de code et le minimum d'efforts pour écrire le code. L'objectif n'est pas de soigner la forme, mais de faire en sorte que le code de production fonctionne, c'est-à-dire qu'il permette de satisfaire le besoin. On valide le comportement et non la structure.
3 - Remanier le code (Refactor)
La dernière étape, celle du refactoring, consiste à remanier le code : on améliore la lisibilité et la flexibilité, sans changer le comportement. L'objectif à cette étape itérative est d'obtenir, in fine, un code qui permette au logiciel d'être fonctionnel et évolutif sur la durée.
Après chaque remaniement, le développeur exécute de nouveau les tests pour s'assurer que le code fonctionne toujours.
Il faut considérer ces 3 étapes de TDD comme une itération d'une ligne de code. Si on adopte une vision plus globale, le processus ressemble à cela :
- Le développeur écrit un test pour chaque fonctionnalité logicielle.
- Il exécute le premier test, qui échoue faute de code de production.
- Le code nécessaire est écrit, et permet de passer le test.
- Le code est « nettoyé ».
- Le deuxième test est exécuté : il échoue.
- La ligne de code correspondante est écrite, et permet de passer le test. Le test précédent est exécuté de nouveau, pour vérifier que la ligne précédente fonctionne toujours.
- Le développeur a désormais deux lignes de code, qu'il remanie : il restructure le code, supprime les doublons, déplace des éléments de manière à simplifier au maximum l'écriture et la lecture.
- Il exécute le troisième test et itère le processus.
Quels sont les avantages de TDD ?
Limiter les bugs
Le principal avantage de Test-Driven Development est la diminution significative des erreurs de codage dans le développement d'un logiciel – à hauteur de 40 à 90 % selon une étude menée par Microsoft en 2008. Le fait de passer les tests oblige les équipes de développement à être rigoureuses et vigilantes.
Lorsque un test échoue alors qu'il passait, cela permet de détecter une régression qui peut tout de suite être corrigée. Le remaniement du code en continu permet d'avoir une amélioration du code et un produit final d'une plus grande qualité.
Avoir un code optimisé
TDD offre l'avantage d'augmenter la confiance en le code. La méthode en effet permet d'obtenir un code optimisé grâce au remaniement constant, et donc un logiciel robuste dans la durée. Le fait d'écrire les tests avant le code permet aux développeurs d'affiner la conception du code objet. Le code est de meilleure qualité et chaque partie est moins dépendante des autres.
Test-Driven Development, par ailleurs, facilite les modifications ultérieures du code, dans un objectif d'évolutivité et d'amélioration continue. Avec un code propre, en effet, les modifications sont moins risquées : le développeur ne craint pas de toucher au code.
Gagner en productivité
Un autre atout de TDD est le gain en productivité des équipes de développement. Cela permet d'optimiser le temps passé à la correction de bugs et de le consacrer à la création du code de production.
La conception, la création des tests et leur exécution requièrent du temps, mais le temps gagné en tests et en vérifications à la fin du projet vient en compensation.
Plus un problème est détecté tôt dans les phases de développement, moins le temps passé à sa correction sera important. Le développeur gagne en productivité et développe une base de code plus flexible. Par conséquent, les coûts sont également réduits.
Obtenir une documentation automatique
Les tests écrits pour les fonctionnalités de l'application peuvent servir de documentation pour l'ensemble de l'application logicielle. Ils permettent de mieux comprendre comment elle est censée fonctionner, et comment elle est conçue. TDD permet donc une meilleure couverture du code.
Quelles sont les limites de TDD ?
Une courbe d'apprentissage variable
Écrire et exécuter des tests, et s'astreindre à faire cet exercice pour chaque ligne de code, impose de se former puis de s'habituer. Certains développeurs peuvent éprouver des difficultés.
Un manque de vision d'ensemble
La granularité des tests et le nombre d'itérations sont tels que l'attention est concentrée sur les détails. Cette méthode de travail risque de contrecarrer la vision d'ensemble du projet.
Un code volumineux
En plus du code de production, le développeur écrit le code pour tester le code de production. Le volume devient rapidement important, ce qui risque de complexifier le développement.
Une charge de travail supérieure
Écrire le test, l'exécuter, écrire le code, le tester, vérifier les lignes précédentes et remanier l'ensemble, ligne après ligne : ce processus itératif peut sembler fastidieux, et risque de décourager.
Comment rester pertinent dans le web 3.0 ?
Téléchargez le guide gratuit et découvrez les pratiques pour adapter votre stratégie aux tendances du web 3.0.
- Avantages
- Caractéristiques
- Mise en place
- Checklist
Télécharger
Tous les champs sont obligatoires.
Merci d'avoir soumis le formulaire
Cliquez sur le lien pour accéder au contenu en tout temps
Quelles sont les méthodes complémentaires de TDD ?
BDD
BDD, pour Behavior Driven Development, est une méthode en amont de TDD, axée sur les scénarios d'utilisation du logiciel. Avant que les développeurs démarrent le travail, les utilisateurs finaux formalisent leurs besoins sous forme de scénarios déroulés dans un langage non technique, avec des exemples concrets, pour permettre aux développeurs de comprendre parfaitement les attentes.
Scrum
Comme TDD, Scrum est une méthode agile. Ce cadre de travail aide à la gestion de projet, et pallie les limites de TDD :
- Chaque itération, appelée sprint en Scrum, est encadrée dans le temps. C'est une bonne manière de rythmer le travail des développeurs et de s'assurer du respect des échéances.
- La méthode Scrum attribue différents rôles, dont celui du product owner (PO) : avec sa vision globale, il veille à la conformité du travail avec le cahier des charges.
Programmation en binôme
En programmation en binôme, un développeur code pendant que l'autre l'observe pour veiller à la bonne conduite du projet. Les développeurs s'échangent régulièrement leur rôle. Pratiquer la programmation en binôme en complément de TDD allège la charge de travail et diminue la pénibilité. La programmation en binôme, par ailleurs, contribue à réduire encore la charge de travail de débogage – réduction estimée à 40 %.
TDD, BDD, Scrum et programmation en binôme : ces méthodes agiles sont initialement conçues pour le développement logiciel. Certains de leurs principes sont transposables, offrant un intérêt notable dans le cadre d'un projet web.
On retient de la méthode TDD le réflexe de tester systématiquement, à un très haut niveau de détails. Imaginons qu'il faille créer un site web à l'aide d'un CMS. À chaque fois qu'une fonctionnalité, un bouton ou un formulaire est ajouté, le concepteur du site utilise le mode aperçu pour en vérifier le fonctionnement. En concevant aussi scrupuleusement le site, brique après brique, le risque d'erreurs est très réduit, et l'entreprise jouit d'une image professionnelle dès le lancement de son site.
Pour aller plus loin, découvrez les opportunités d'affaires liées aux évolutions du web en téléchargeant le guide et la checklist ultime du web 3.0, ou découvrez le logiciel marketing de HubSpot. 
