TDD : le guide pour comprendre le test-driven development

Le développement piloté par les tests ou Test-Driven Development (TDD) est une méthode de conception très répandue parmi les développeurs. Contrairement à d’autres pratiques, comme le E2E, il consiste à rédiger les tests avant même d’avoir commencé à écrire le code source.

Cette approche apporte un haut niveau de qualité et de fiabilité au projet développé en permettant au développeur d’écrire le code de manière très claire et logique, grâce à la détection des erreurs dès les premières étapes de développement.

En quoi consiste exactement le TDD ? Quels sont ses avantages et inconvénients ? Comment le mettre en place dans votre processus de développement ? Suivez le guide de Freelance Informatique !

Qu’est-ce que le test-driven development ?

Le test-driven development consiste à développer un logiciel ou une application web de manière incrémentale, par des itérations successives très courtes, appelées “petits pas”. Ainsi, pour chaque fonctionnalité spécifique que l’on souhaite coder, on commence par rédiger un test spécifique et très ciblé.

Plutôt que de tester des unités de code, des fonctionnalités ou l’ensemble d’une application, comme dans le cadre de tests unitaires ou de tests système, l’objectif est de formuler une hypothèse répondant à un problème, qui va servir de base dans la rédaction du code. On cherche à vérifier un comportement : la manière dont le code va être exécuté en fonction des données d’entrée, ainsi que les informations renvoyées en sortie.

Le terme test unitaire est parfois utilisé pour décrire le TDD, ce qui peut porter à confusion. Dans ce contexte, on ne désigne pas un test qui porte isolément sur la plus petite unité de code, mais sur une unité de comportement fonctionnellement indépendante.

Particulièrement utilisé dans le développement des applications web et mobiles, le TDD permet de s’adapter en continu aux évolutions rapides des outils, exigences et technologies de ce secteur. En raison de leurs exigences élevées en matière de fiabilité et de réactivité, les logiciels SaaS (Software as a Service) ont également souvent recours à cette méthode.

Cette logique de développement agile s’intègre aussi aisément avec le CI/CD (Continuous Integration/Continuous Delivery) qui permet l’intégration et la livraison continue des applications, mais aussi avec la philosophie DevOps, qui a pour but d’unifier le monde du développement logiciel et l’univers des opérations informatiques.

Le test-driven development est issu du TFD (Test-First Design). L’ingénieur logiciel Kent Beck, à l’origine du concept, a ainsi eu l’idée d’inverser le processus de développement en concevant les tests comme des hypothèses avant même de commencer à coder, au lieu de contrôler une fonctionnalité déjà réalisée.

Cependant, le test-first design agit à un niveau moins granulaire que le TDD : après avoir écrit le test, la fonctionnalité doit être codée en une seule étape, suite à laquelle le test est exécuté. Le TDD, quant à lui, agit de manière incrémentale : la fonctionnalité est découpée en plusieurs itérations pour lesquelles un code minimal est rédigé afin de passer le test, puis est refactorisé par la suite.

Quels sont les avantages du test-driven development ?

Le TDD comporte de nombreux avantages : cette méthode de conception agile permet la production d’un code d’une grande fiabilité avec un niveau de performance élevé.

Les principaux atouts de cette pratique sont les suivants :

• Haut niveau de qualité du code : en détectant les bugs le plus rapidement possible, le test-driven development prévient les régressions et les bugs et donne lieu à la production d’un code léger et optimisé ;
• Parfaite adéquation avec les besoins métiers : rédiger les tests en amont demande une compréhension approfondie des spécifications fonctionnelles. En passant les tests, le logiciel développé répond ainsi parfaitement au besoin ;
• Maintenance et évolutivité : grâce à une base de tests robustes, le projet s’adapte aisément aux changements de spécifications, aux modifications du besoin et aux mises à jour imposées ;
• Documentation précise : les tests constituent une documentation vivante du code, très précise et fréquemment actualisée. Cela facilite l’onboarding des nouveaux développeurs sur un projet en diminuant le temps dédié à la documentation ;
• Gain de temps et d’argent : malgré un investissement de temps important lors de la rédaction des tests, le TDD permet de réduire les coûts de développement. Il améliore la qualité du code et accélère donc considérablement l’étape de débogage lors de la mise en production, ainsi que la maintenance.

Quelles sont les limites du TDD ?

Si le test-driven development comporte de nombreux avantages, cette méthode de développement comporte aussi quelques limites qui peuvent freiner son adoption par certains développeurs :

• Temps initial d’écriture des tests : mettre en place une démarche TDD nécessite une augmentation du temps de développement initial consacré à la rédaction des tests et à la compréhension approfondie des besoins ;
• Complexité des tests : pour les systèmes larges qui demandent un développement important, les tests peuvent exiger une certaine complexité de rédaction et de gestion ;
• Présence de code non testable : il arrive qu’une grande partie du code existant soit difficile à tester. Des techniques particulières, telles que l’injection des dépendances, sont alors mises en place pour répondre à ce problème ;
• Test du code et non de l’utilisabilité de l’application : le test-driven development a pour objectif de contrôler la qualité, la fiabilité et l’efficacité du code, mais il ne s’intéresse pas à la facilité d’utilisation du logiciel. D’autres types de tests, axés sur les attentes des utilisateurs, peuvent alors être mis en place par les développeurs, comme les tests fonctionnels.

Comment mettre en place le TDD ?

Le cycle de développement en TDD

Si les procédures conventionnelles de test font appel à des modèles en cascade ou en V, le TDD est organisé sous la forme d’un cycle qui comporte plusieurs phases afin d’écrire le code de manière incrémentale.

La première phase dite “red” ou rouge se déroule selon les étapes suivantes :

• Écrire le test pour répondre à un problème, en toute connaissance du besoin et des fonctionnalités souhaitées. Le développeur doit ainsi identifier les éléments indispensables pour que le test soit fonctionnel ;
• Exécuter le test et vérifier qu’il échoue : il doit en effet obligatoirement et volontairement mener à l’échec à ce stade étant donné que le code à tester n’a pas encore été écrit.

La phase dite “green” ou verte, intervient alors. Elle consiste à produire le code minimal pour passer le test, en se concentrant sur la simplicité. Le seul objectif est ici de réussir le test en ne rédigeant que le strict nécessaire.

Enfin, la dernière phase intervient : dite “refactor” ou “refactoring”, elle consiste comme son nom l’indique à refactoriser le code pour l’alléger, l’optimiser et le rendre plus performant. On doit ainsi notamment éviter les duplications pour que le code source soit lisible et propre. Bien entendu, les mêmes fonctionnalités sont conservées et les tests sont exécutés à nouveau pour s’assurer qu’ils ne mènent pas à un échec.

Les outils utiles pour le TDD

De nombreux outils existent pour faciliter votre démarche de test-driven development. Ils vont notamment intégrer un rappel des fonctionnalités souhaitées, des fonctions de refactorisation et d’automatisation pour exécuter le test sans supervision continue ou encore la capacité à déclencher le cycle “red, green, refactor” du TDD.

Voici une liste non exhaustive des outils TDD les plus populaires :

• JUnit : il permet d’exécuter des plans de test sur une machine virtuelle Java ;
• Pytest : ce framework de test est quant à lui basé sur Python ;
• NUnit : cet outil est conçu pour les logiciels développés en .NET ;
• RSpec : ce dispositif peut être utilisé si le langage Ruby est utilisé.

On retrouve bien d’autres technologies pour accompagner les équipes techniques dans leur procédure TDD : Mockito, TestNG, Cucumber, TestRail ou Cypress peuvent notamment être cités.

Les autres procédures de tests : le BDD et le DDD

D’autres approches de développement ont vu le jour ces dernières années, comportant une vision différente du processus de rédaction du code.

Le BDD ou Behavior-Driven Development

Appelé programmation pilotée par le comportement, le BDD est en pleine expansion. Les développeurs se concentrent cette fois-ci sur le comportement souhaité du logiciel et donc le résultat attendu lors de l’exécution du programme.

Cette méthode de développement agile ne nécessite pas une compréhension technique approfondie du code comme c’est le cas pour le TDD et permet donc d’impliquer toutes les parties prenantes en développant la prise de décision collective. Le métier, le Product Owner, le testeur QA (Quality Assurance) et le développeur collaborent ainsi pour créer une application basée sur le comportement attendu de la part de l’utilisateur.

À l’instar du TDD, la solution est autodocumentée : la rédaction des scénarios de tests par les équipes sert de documentation.

Le DDD ou Domain-Driven Design

Avec l’approche DDD ou conception pilotée par le domaine, le développement est axé sur le métier. L’expertise métier est utilisée pour concevoir un code qui répond aux exigences du domaine et qui est donc intelligible par le métier. Plus que d’apporter une réponse technologique avec un langage de programmation particulier, on va chercher à répondre à une problématique métier en collaboration avec les équipes.

La méthode DDD repose sur deux principes : les conceptions complexes doivent être fondées sur une modélisation, par exemple sous forme de diagrammes UML (Unified Modeling Language) et l’accent est mis sur le domaine et la logique associée.

À retenir sur le TDD

• Le TDD ou développement piloté par les tests consiste à rédiger les tests en amont du développement et à concevoir le code selon un cycle en trois phases : red, green et refactor ;
• La production du code a lieu de manière incrémentale, via des itérations successives très courtes appelées “petits pas” ;
• Cette méthode permet d’assurer un haut niveau de qualité du code, ainsi qu’une maintenance et une évolutivité optimisées, une documentation précise et un accroissement de la productivité des équipes qui se traduit par une diminution des coûts ;
• Ce n’est pas la seule approche existante : le BDD ou le DDD sont aussi en forte expansion.