TDD ou le développement piloté par les tests

T.D.D. (pour Test Driven Development) est une méthode agile qui est issue du manifeste Software Craftsmanship.

On a tous entendu parlé du Manifeste agile, rédigé par 17 experts du logiciel et qui comporte 4 grandes valeurs :

Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan

Le manifeste Software Craftsmanship est un autre manifeste qui étend le manifeste agile.

Il prône, entre autres, le fait qu’il ne suffit pas que le logiciel fonctionne, il faut également qu’il soit correctement écrit. L’accent est notamment mis sur la fiabilité et la facilité de maintenance. Les développeurs forment alors une véritable communauté d’experts, de véritables « artisans du code » aux petits soins du logiciel.

Ses valeurs sont les suivantes :

Pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus.
Pas seulement l’adaptation aux changements, mais aussi l’ajout constant de la valeur.
Pas seulement les individus et leurs interactions, mais aussi une communauté de professionnels.
Pas seulement la collaboration avec les clients, mais aussi des partenariats productifs.

De ce manifeste, plusieurs « bonnes » pratiques de développement et de gestion de projet ont, dès lors, été mises en avant :

Le pair-programming : on programme mieux à 2 cerveaux que lorsqu’on est seul face à son écran
La revue de code : pour que le code soit partagé à l’équipe avant mise en production, trouver les bugs, échanger sur les standards et pratiques de l’équipe…
Clean-code : un code simple et clair, principes KISS, SOLID etc.
Legacy refactoring : pour se réapproprier un code existant qui n’a pas été écrit par nous-même
B.D.D. : pour Behaviour Driven Development, ou le développement piloté par les scénarios
et enfin T.D.D., que nous allons détailler ensuite

Les tests unitaires

Avant d’entrer sur le détail de la méthodologie T.D.D., je vous propose de faire un rappel sur les tests unitaires. Selon Wikipédia :

En programmation informatique, le test unitaire (ou « T.U. », ou « U.T. » en anglais) ou test de composants est une procédure permettant ade vérifier le bon fonctionnement d’une partie précise d’un logiciel ou d’une portion d’un programme (appelée « unité » ou « module »).

Ce qu’il faut savoir :

Chaque langage possède au moins un outil / framework de tests unitaires (C#, Java, Ruby, PHP, JavaScript…)
Chaque test unitaire doit être indépendant et rejouable à l’infini
Chaque test unitaire doit se dérouler au sein d’un environnement isolé. Pas d’appel à une base de données, webservice, système de fichiers, etc…
Utilisation des stubs / mocks : ce sont des objets simulés qui reproduisent le comportement d’objets réels de manière contrôlée (une base de données, webservice, API, etc.)
L’ensemble des tests unitaires doit être rejoué après une modification du code afin de vérifier qu’il n’y a pas de régressions.

Pourquoi tester un logiciel ?

Pour être sûr que le code écrit fait bien ce qu’il est censé faire
Pour obtenir un feedback rapide sur les régressions causées par des modifications de code
Pour sécuriser les phases de refactoring. Un test automatisé au rouge montrera plus rapidement une incohérence qu’un test manuel
Pour mettre en avant les problèmes de conception et d’architecture : si poser un test unitaire sur un code s’avère compliqué, c’est que l’architecture n’est pas bonne
Maîtriser, et même limiter la dette technique

On a tous en tête la fameuse histoire du bug qui s’est produit pendant le vol 501 d’Ariane 5. Je vous réfère au Top 10 des erreurs de programmation les plus connus de l’histoire.

Présentation de la méthodologie de T.D.D.

En processus logiciel dit « classique », les tests unitaires sont rédigés après le codage d’une fonctionnalité. Dans ce cas de figure, ils sont là pour valider du code :

La méthodologie TDD consiste à poser d’abord un test unitaire, puis à écrire le code permettant de valider ce test. Les tests nous aident donc à spécifier du code :

Le test unitaire sert à spéficier un code

Dans une approche classique, les tests permettent de trouver, déceler des bugs.
En TDD, les tests servent à prévenir, éviter les bugs.

3 étapes clés : RED -> GREEN -> REFACTOR

Tout d’abord, je crée mon projet de tests, puis je crée ensuite une classe de test MyClassTest correspondant à la classe MyClass que je veux tester.

La méthodologie T.D.D. est un cycle continu de 3 actions précises :

J’écris un test unitaire que je fais passer au rouge (RED)
J’écris le code le plus simple possible pour faire passer le test au vert (GREEN)
Je refactorise mon code pour le rendre plus propre ou plus lisible si besoin (REFACTOR)

Voici un autre workflow plus complet :

Comment m’initier à T.D.D. ?

Le premier livre sur T.D.D. « Test Driven Development by Example » a été écrit en 2000 par Kent Benk.

Je vous invite aussi à regarder lire les articles suivants :

ainsi qu’à regarder la vidéo ci-dessous où vous verrez directement la mise en place de T.D.D. sur un nouveau projet.

Les outils

Selon le langage que vous utilisez, vous aurez besoin d’outils supplémentaires.

En C#, vous aurez besoin des packages NuGet suivants :
- Moq : pour créer des stubs et des mocks facilement
- Shouldly (facultatif) : pour simplifier l’écriture des assertions
En Typescript ou Javascript, vous aurez besoin des packages Karma et Jasmine que vous pourrez obtenir via NPM.
Je vous invite lire cet article pour vous initier https://atomrace.com/tester-son-application-angular-avec-karma-et-jasmine/

Combien ça me coûte en plus de mettre du T.D.D. en place sur mon projet ?

Effectivement, il est l’heure de parler ROI et budgets.

Certains annoncent 10% de plus, 30% de plus….
La bonne question à se poser est en fait : Combien me coûte en plus chaque bug déclaré en recette ou en production par rapport à s’il avait été découvert lors de la phase de développement ou de conception ?

Il y a en réalité 2 temps forts à comparer :

Différence de temps pour développer le logiciel avec TDD et sans TDD ? (build)
Différence de temps pour maintenir le logiciel avec TDD et sans TDD ? (run)

On peut voir ici que le temps consacré au build d’un projet est plus court lorsqu’on développe sans TDD.
On peut également voir aussi que le temps consacré au run d’un projet est plus long lorsqu’on développe sans TDD.
Le temps passé à identifier, corriger et redéployer un ou plusieurs bugs coûte très cher et fait exploser le budget global.

Selon Google, un bug identifié chez eux leur coûte suivant le tableau :

Contexte	Coût
En local grâce à un test unitaire	5$
Un test unitaire qui échoue lors de la build	50$
Sur l’environnement de test	500$
Sur l’environnement de production	5000$

Selon OCTO, il faut 3 mois à une équipe pour être suffisamment à l’aise avec la méthodologie T.D.D.