Test-driven development : le développement piloté par test

Le test-driven development est une technique de développement logiciel pilotée par les tests. Une méthode agile qui pousse les développeurs à corriger les bugs au fur et à mesure de la programmation d'une application.

Le test-driven development (TDD), c'est quoi ?

Le test-driven development (TDD) renvoie à une technique de développement logiciel qui vise à réduire les anomalies d’une application en favorisant la mise en œuvre fréquente de tests. Une politique de test first, en cohérence avec les méthodes agiles, qui pousse les programmeurs à faire preuve de plus de rigueur et à corriger en quasi temps réel les bugs et autres erreurs dans le code source. Au départ, le test-driven development préconise de concevoir les tests avant même de développer en suivant l'approche du test first design. Comme l'explique l'expert Xavier Pigeon, le TDD, a depuis, évolué vers plus de granularité, ce qui a engendré l'émergence de trois lois sous-tendant la démarche :

"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".

"Le fait de mettre bout à bout les trois lois du TDD en une seule itération constitue ce qui est appelé un nano-cycle de TDD", précise l'expert. "Au final, ces lois sont à la charnière des étapes de la phase amont du TDD, appelée code-driven testing" (voir le schéma ci-dessous).

Quels sont les bénéfices du test-driven development ?

Ecrire les tests en amont du codage permet de facto une couverture de test unitaire élevé. Ce qui se traduit par une meilleure qualité des développements, mais aussi du refactoring de code (une opération notamment réalisée lors de la migration d'applications d'une infrastructure cloud à l'autre par exemple).

Avec pour objectif de détecter les bugs le plus en amont possible, le test-driven development, quand il est correctement mis en place, minimise par ricochet les erreurs et autres problèmes une fois le déploiement réalisé. La maintenance s'en trouve facilitée avec, à la clé, des gains de temps potentiellement substantiels en production.

Comment utiliser le test-driven development (TDD) ?

Le concept de test-driven development préconise cinq étapes. Un processus qui sera réitéré autant de fois que nécessaire jusqu'à la résolution intégrale des bugs détectés. Ces cycles itératifs sont baptisés micro-cycles de TDD. Voici les cinq phases en question :

Rédiger un test unitaire ne décrivant qu’une seule partie de la problématique posée
Confirmer l’échec du test
Ecrire cette fois-ci un morceau de code suffisant pour qu’il réussisse le test
Confirmer la réussite du test
Améliorer le code et contrôler l’absence de régression.

Exemple de test-driven development (TDD)

Plus concrètement, le test-driven development se déroule par cycle de trois phases : rouge (red), green (vert) et remaniement (refactor). En amont, le développeur doit commencer par écrire un test unitaire. Par essence, ce dernier va obligatoirement échouer, puisque le code testé n’a pas encore été créé. Le test unitaire est donc symbolisé par la couleur rouge.

Dans un second temps, le programmateur écrit suffisamment de code pour que le test unitaire réussisse et passe au vert. Enfin, l’étape du remaniement, elle, consiste comme son nom l'indique à remanier le code en contrôlant que tous les tests réalisés restent bien en vert.

Test-driven development en Java

Java figure parmi les langages de développement les plus utilisés. Son principal atout historique ? Sa portabilité entre les différents systèmes d’exploitation : Windows, Linux, Mac, Unix… Il sert également de base à la grande majorité des applications d'entreprise en réseau. Voici un tutoriel sur l'application du test-driven development au langage Java (en français).

Test-driven development en C#

Distribué par Microsoft depuis 2002, C# est un langage de programmation proche de Java. Comme ce dernier, il est orienté objet. C# est surtout employé pour des applications et des services web, mais aussi des widgets et quelques applications de bureau. C# est conçu pour la plateforme Microsoft .NET. Retrouvez ici un tutoriel sur le test-driven development en C# (en anglais).

Test-driven development en PHP

PHP est principalement utilisé pour le développement web. C'est aussi un langage orienté objet qui est à l’origine d’un grand nombre de sites Internet. Voici un exemple de mise en pratique du test-driven development à PHP (en français).

Test-driven development en Python (avec Json)

Utilisé à la fois dans la programmation de sites web et d'applications, Python est un langage de développement de plus en plus prisé. Une tendance qui s'explique par son potentiel, ses performances, mais aussi et surtout sa facilité de prise en main. Avec l'émergence de l'IA, Python est également devenu un environnement de référence en data science, notamment pour les projets de machine learning et de réseaux de neurones artificiels. Découvrez un guide (en anglais) pour mettre en pratique le test-driven development en Python (en utilisant un schéma Json).

Le test-driven design (TDD), qu'est-ce que c'est ?

Affublé du même acronyme que le test-driven development, le test-driven design (TDD) renvoie à une autre manière de définir ce dernier. Il faut bien comprendre que les tests ne constituent pas l'objectif du test-driven design mais sont, au contraire, un outil au service de de la conception du codage. Résultat : certains développeurs préfèrent parler de test driven design, autrement dit de conception (logicielle) pilotée par les tests.

Test-driven design (TDD) vs acceptance test-driven development (ATDD), quelles différences ?

L'acceptance test-driven development (ATDD) est complémentaire du test-driven design (TDD). L'ATDD consiste à concevoir les tests logiciels en vue de vérifier qu'un scénario applicatif est globalement en ligne avec ce qui est recherché.

L'acceptance test-driven development est très similaire au behavioral-driven development (BDD). L'approche est néanmoins légèrement différente. Alors que le premier est centré sur des tests d'acceptation fonctionnelle, le processus d'envoi d'un mail par exemple, le second cherche à vérifier le bon comportement de chaque fonction. Dans notre exemple, il s'agira de vérifier que chaque étape de l'envoi d'un message répond bien aux exigences voulues.