Il existe depuis longtemps différentes méthodes permettant de contrôler la qualité des logiciels. Au tout début, le développement concret des logiciels et leurs tests étaient encore considérés comme des processus indépendants l’un de l’autre, jusqu’à l’arrivée du Test Driven Development.

Quelle est l’origine du Test Driven Development ?

Aux prémices de Test Driven Development (TDD), le Test First Design qui consistait à écrire les tests avant de coder.

L’approche Test-First a été développée par Kent Beck, développeur de logiciels américain et fondateur de l’eXtreme Programming, en inversant le processus utilisé jusque-là : au lieu de commencer par écrire le code source et de le tester ensuite, l’équipe de développeurs commence par écrire le test. Les scénarios de test sont alors utilisés pour écrire et implémenter le meilleur code possible.

La méthode évolue ensuite vers une granularité plus fine de développement : pour une ligne de test en échec, une ligne de code de production est écrite pour faire réussir le test

Tandis que les procédures de test en aval utilisent un modèle en cascade ou en V, les processus du TDD sont cycliques et adpatées aux méthodes agiles. C’est une pratique très connue dans le domaine de l’intégration continue CICD de la démarche DevOps. Le TDD permet principalement d’amener les développeurs à trouver une solution à une demande posée par le test.

Plus concrètement vous devez :

• Décrire un problème par l’écriture d’un test.
• Exécuter le test et s’assurer qu’il échoue ; vu que le code à tester n’existe pas encore.
• Coder juste ce qu’il faut pour assurer la réussite du test
• Vérifier la réussite du test en question avec l’exécution d’autres tests.
• Remanier (refactor) le code ; améliorer sa qualité sans modifier le comportement, en d’autres termes retravailler le code source en conservant les mêmes fonctionnalités.

Le Test Driven Development se déroule par cycle de trois phases : red (rouge), green (vert) et refactor (remaniement).

TDD Phase Red

En amont, le développeur doit commencer par écrire un test unitaire. Celui-ci va obligatoirement échouer puisque le code à tester n’a pas encore été créé. Ce test unitaire est donc symbolisé par la couleur rouge.

Dans cette phase, vous vous mettez à la place de l’utilisateur. Celui-ci veut pouvoir utiliser simplement le code. Vous écrivez donc un test, qui contient des composants qui n’ont pas encore été implémentés. Vous choisissez les éléments indispensables pour que le code soit fonctionnel.

TDD Phase Green

Dans un second temps, le développeur écrit le code suffisant pour que le test unitaire réussisse et passe au vert.

Dans cette phase, le développeur essaie de trouver une solution simple en n’écrivant que le strict nécessaire puis l’intègre dans le code de production afin que le test soit marqué en vert.

TTD Phase refactor

Enfin, l’étape du refactoring, elle, consiste comme son nom l’indique à remanier le code en contrôlant que tous les tests réalisés restent bien en vert.

Dans cette étape, vous n’avez plus qu’à structurer et éventuellement compléter le code de production pour qu’il soit lisible et propre en supprimant la duplication des codes par exemple.

Il faut bien évidemment veiller à ce que les différentes activités de chacune des phases ne se chevauchent pas.

Comment fonctionne le Test Driven Development ?

C’est une procédure cyclique et incrémentale qui garantit que le code transféré au système de production répond à toutes les attentes. Cette méthode permet d’enrichir le logiciel de nouvelles fonctions étape par étape, un nouveau code source étant écrit après chaque test réussi.

Les scénarios individuels de test ne passent généralement que quelques secondes ou minutes dans le cycle par conséquent, les résultats sont rapidement visibles dans le code de production. Les développeurs utilisent généralement un outil de moteur d’intégration comme CruiseControl ou Jenkins. Cela permet d’assurer l’intégration des composants en continu et sans erreurs dans le code source. En général, les tests sont écrits dans le même langage que le code de fonction.

Quels sont les bénéfices du Test Driven Development ?

Le TDD permet de s’assurer que la conception d’un logiciel est bien pensée avant de commencer à écrire le code.

Ecrire les tests en amont du code permet une couverture de test unitaire élevé mais aussi une pertinence de ces tests, dans la mesure où ils répondent parfaitement aux besoins métiers. On évite ainsi les pertes de temps à réaliser des fonctionnalités dont le résultat ne sera pas satisfaisant !

Avec pour objectif de détecter les bugs le plus en amont possible, le test-driven development, minimise les erreurs et autres problèmes une fois le déploiement réalisé et notamment les régressions. La maintenance s’en trouve facilitée avec, à la clé, des gains de temps potentiellement substantiels en production et une meilleure qualité des développements

La suppression des redondances dans le code permet d’éviter également la suringénierie

Quels sont les inconvénients du Test Driven Development ?

• Nécessite la compréhension du code et exige peut-être une période de formation plus longue.
• Teste uniquement l’exactitude du code et non la facilité d’utilisation du logiciel.
• Doit éventuellement être complété par d’autres procédures de test.

Quelles sont les autres procédures de test ?

Le Test Driven Design

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 à savoir la conception logicielle pilotée par les tests, le test-driven design étant un outil au service de la conception du code.

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

Qu’est-ce qui distingue le Test Driven Development des autres procédures de test ?

Le Test Driven Development est une stratégie de conception, qui guide le processus de développement d’un logiciel au moyen de différents tests. Contrairement aux processus en aval, les scénarios de test de la méthode TDD sont effectués dès le début de la conception du logiciel. Les tests utilisés dans le contexte du TDD diffèrent par leurs objectifs et leurs portées. Le test le plus simple est le test unitaire. Il est utilisé pour tester les composants individuels d’un programme informatique. Les tests d’intégration et fonctionnels qui permettent de vérifier l’interaction des différentes parties du système et la fonctionnalité globale d’un logiciel sont plus complexes.

Depuis quelques années le Behavior Driven Development (BDD), également appelé programmation pilotée par le comportement, se développe. L’équipe de développeurs se concentre non pas sur l’exactitude du code, mais sur le comportement souhaité du logiciel. Il n’est pas nécessaire d’avoir une compréhension technique du code pour écrire des scénarios de test et il est donc possible d’impliquer les parties prenantes dans le processus de développement.

Alors que le Test Drivent Development assure une architecture propre, le BDD propose la meilleure approche dans l’écriture.

Le Domain Driven Design (DDD) a, quant à lui, l’objectif de définir une vision et un langage partagés par toutes les personnes impliquées dans l’élaboration d’une application, afin de mieux en appréhender la complexité

En résumé

Avec l’approche DDD, on conçoit une application qui reflète la complexité du métier avec l’aide des métiers

Ave l’approche BDD, on affine les attendus du logiciel

Avec l’approche TDD, on consolide l’application par des tests unitaires pour diminuer les régressions

Ces 3 approches qui interviennent à des niveaux différents de la conception d’un logiciel sont très complémentaires. Bien que leur maîtrise demande un investissement initial, elles ont toutes les 3 pour objectif d’aider les équipes à créer des logiciels de très grande qualité.

Ce trio TDD, BDD, DDD permet ainsi de :

• concevoir un logiciel qui saura évoluer sur le temps
• offrir un logiciel qui répondra réellement aux besoins
• diminuer la dette technique potentielle
• limiter les ralentissements des futures évolutions souvent dues à des systèmes de plus en plus complexes

Le Test Driven Development s’inscrit donc dans une approche plus globale de qualité logicielle et de réduction de la dette technique. Nos équipes peuvent vous accompagner dans la mise en place d’une démarche TDD ou d’une évaluation 360° de la qualité de vos applicatifs et du respect des bonnes pratiques de développement logiciel.