TDD : une approche à abandonner ?

Le TDD pour Test Driven Development ou développement piloté par les tests en français consiste à créer un code qui teste si le code du projet réel fonctionne comme prévu. Ce processus de développement de logiciels implique de concevoir d’abord des scripts de tests, avant de se lancer concrètement dans la programmation de l’application. Cette méthode est souvent citée dans les bonnes pratiques de développement, car elle permet d’obtenir des applications de meilleure qualité. Pourtant, le TDD reste peu utilisé par les développeurs car il demande beaucoup de temps pour la création et l’exécution des tests. Le Test Driven Development est-il pour autant une approche à abandonner ? Découvrez dans cet article les avantages et risques du développement piloté par les tests.

Le Test Driven Development : en quoi ça consiste ?

Définition et étapes du TDD

Avant de présenter les avantages et inconvénients du TDD, il est indispensable de bien comprendre en quoi consiste ce processus. Le TDD est une méthode de développement qui regroupe la programmation, les tests unitaires et la refactorisation (aussi appelée amélioration continue).

Plus concrètement ; les équipes de développement vont créer des cas de tests pour chaque fonction de leurs applications, les exécuter et, si les tests échouent, modifier le code jusqu’à ce qu’ils réussissent. En quoi est-ce différent des méthodes de tests traditionnels et automatisés ? La différence majeure est qu’avec le TDD les tests sont conçus et programmés avant que la moindre ligne de code de la fonctionnalité soit écrite. Le test décrit le comportement attendu d’une interface et celle-ci est ensuite développée selon les différents résultats d’exécution des tests.

Le framework TDD repose sur plusieurs étapes :

• 1) Rédiger un test unitaire décrivant une seule partie de la problématique posée ;

• 2) Confirmer l’échec du test ;

• 3) Écrire le minimum de code nécessaire pour la réussite du test ;

• 4) Exécutez le test pour confirmer sa réussite ;

• 5) Répétez en refactorisant le code et en contrôlant l’absence de régression.

  
  

Un exemple simple de TDD

Pour mieux comprendre le framework TDD, prenons l’exemple d’une salle de sport qui vend des abonnements en tenant compte de l’âge de l’acheteur. Pour développer cette application avec le TDD, il faut commencer par rédiger un test simple :

public void test_age() {

int tarif = get_tarif_age(3) ; 

assertEquals(« Les enfants de moins de 3 ans ne peuvent pas s’abonner à la salle », -1,tarif) ; 

}

Dans cet exemple, la fonction get_tarif_age() renvoie le tarif pour un âge donné. La règle établie est qu’un enfant de 3 ans n’est pas autorisé à prendre un abonnement à la salle de sport. L’étape suivante consiste à écrire le code minimal nécessaire pour réussir à passer le test, ce qui peut être fait en mode TDD pur :

public static int get_tarif_age(int age) { 

   return -1 ; 

}

Ce code passe le test, mais ne répond bien sûr pas aux exigences fonctionnelles. Un autre exemple, plus réaliste, de test pourrait être : 

public void test_trente() { 

int tarif = get_tarif_age(30) ; 

assertEquals(“Les personnes de 30 ans ont un abonnement à 50 €/mois”, 50, tarif) ; 

}

Le développeur devra alors ajouter les instructions retourner 50 € par mois si l’âge reçu en entrée est égal à 30 (ou sur des fourchettes d’âge) puis passer au test suivant. Toutes les autres entrées et fonctionnalités seront testées puis développées selon ce modèle.

Les avantages du développement piloté par les tests 

Le principal avantage du TDD est de diminuer les bugs et dysfonctionnements des applications puisque tous les tests sont passés plusieurs fois et tout au long du processus de développement. Cette approche oblige les programmeurs à être particulièrement rigoureux car chaque test qui échoue demande une correction immédiate. De plus, cette approche permet de détecter la moindre régression et de refactoriser en permanence le code.

L’autre avantage principal est d’obtenir une application globalement mieux conçue puisque le fait d’écrire les tests avant le développement pousse les équipes à réfléchir davantage aux fonctionnalités attendues et à passer davantage de temps sur la phase de conception du projet. Le test driven development est régulièrement associé aux méthodes XP, Scrum XP et à l’approche devops. 

Les autres bénéfices de l’approche TDD sont :

• une conception du logiciel plus modulaire, les développeurs se concentrant sur une fonctionnalité à la fois ;

• un code plus facile à maintenir, car plus synthétique, propre et lisible ;

• une meilleure documentation, car les tests unitaires peuvent servir de commentaires pour illustrer comment le code doit fonctionner.

Les risques du test driven development

Le fonctionnement du TDD révèle une de ses faiblesses majeures : le temps nécessaire à son implémentation. Écrire les tests à l’avance signifie logiquement que le projet prendra beaucoup plus de temps à se lancer. Cela dépend en fait de l’architecture de l’application. L’exemple fourni précédemment est simplifié et la plupart des programmes comprennent des dépendances ou font appel à des données et services externes qui peuvent venir invalider les tests.

Les TDD peuvent aussi être coûteux en temps et en argent sur les projets où les besoins ne sont pas clairement définis. Si les fonctionnalités attendues changent, les anciens tests deviennent inutiles et la perte de temps est beaucoup plus importante que si les développeurs avaient seulement conçu le code « réel » de l’application. De même, toutes les évolutions ou modifications apportées au code existant impliquent que les tests soient maintenus, modifiés et exécutés de nouveau plusieurs fois.

Enfin la méthodologie TDD peut être assez complexe à prendre en main et nécessite que tous les développeurs d’un même projet appliquent ce framework au risque de manquer des tests ou d’en laisser certains sans maintenance. 

Les inconvénients du TDD sont donc surtout liés à la nature des projets et à leur cadre. Ce n’est pas une approche à abandonner, mais à réserver aux applications où les entrées et sorties sont clairement définies. Pour ces cas, le processus de tests driven development permet de concevoir des programmes fiables, efficaces et plus faciles à maintenir. À l’inverse, le TDD peut être trop délicat à mettre en place sur des applications déjà existantes ou à la configuration complexe.

Utilisez-vous régulièrement le framework TDD dans vos projets et missions ? N'hésitez pas à nous partager vos retours d’expérience sur le forum IT.