Test Driven Development

Découvrez une des pratiques de la méthode agile XP

tdd-agilaction

Le concept :

Le TDD : Test Driven Development est une technique de développement qui découle de la méthode agile XP (Extremme Programming).  Plus précisément : elle repose sur le principe « Test First » de la méthode XP. Le TDD est une pratique rejoignant les valeurs de l’agilité notamment la livraison rapide et fréquente de composants logiciels fonctionnels et aussi l’amélioration continue.

La méthode TDD préconise de guider le développement d’une application par l’écriture de tests unitaires. Avant même de toucher au code source on va donc commencer par écrire les test qui vérifieront ce code.  On part de ces tests pour développer et améliorer à chaque fois le code en fonction des erreurs remontées par les tests.

Règles et pratiques

La démarche à suivre est la méthode Mantra divisée en trois étapes « RGR » qui sont les suivantes :

Red : Ecrire un test et le faire échouer

Green : Ecrire le code  qui valide le test

Refractor : Remanier le code afin d’améliorer la qualité

Plus concrètement, un Cycle TDD se déroule de la manière suivante :

  • On écrit un seul et unique test unitaire décrivant un aspect du programme ou de l’application.
  • On vérifie que ce teste échoue car étant donné qu’aucun code n’est écrit il ne doit pas réussir à passer.
  • Ensuite on écrit un code minimaliste, le plus simple possible juste suffisant pour que ce test passe.
  • Une fois le test validé on « réusine » le code autant que nécessaire (on l’améliore en gardant les mêmes fonctionnalités)
  • Puis on répète le processus en accumulant les tests au fur dès que l’on ajoute du code.

Erreurs à ne pas commettre :

Les erreurs les plus souvent commises concernant les tests eux-mêmes sont :

  • Ne pas tester fréquemment
  • Ecrire trop de tests en même temps
  • Ecrire des tests inadaptés

Concernant l’organisation de l’ équipe face à cette pratique :

  • Une adoption de la méthode incomplète : seulement une partie de l’équipe pratique le TDD
  • Une batterie de test trop longue à dérouler
  • Délaissement de cette batterie de test

Avantages

Les tests sont indispensables pour assurer la qualité d’une application ou d’un programme, seulement on remarque que très souvent l’écriture de ces derniers sont un peu délaissés ou remis à plus tard car si l’application fonctionne on n’y voit pas d’urgence. Cette pratique va permettre de nous assurer que non seulement ces tests sont écrit mais surtout qu’ils sont respectés et fonctionnels.

Grâce au TDD les développeurs vont aussi pouvoir clarifier les détails de l’interface en anticipant le code. En effet lorsque le dev va écrire les test il va devoir réfléchir à la méthode qu’il va employer pour passer ces tests et cette étape préalable lui permettra donc par anticipation de n’écrire que du code « utile ».

Cette pratique permet aussi de s’assurer que le code est testable unitairement avant même de l’avoir écrit. On facilite la production d’un code plus juste et plus fiable.

De cette manière le code est protégé au fil de son développement mais il est aussi et surtout documenté !

Controverses 

Malgré ses atouts évidents, le TDD comme toutes les pratiques agiles a lui aussi sa part de critiques.

David Heinemeier Hansson le créateur du Framework Ruby on Rails a remis en cause la pratique lors de sa Keynote d’ouverture de la Railsconf en 2014. Il a par la suite écrit plusieurs articles appuyant son point de vue notamment « TDD is Dead – Long Live Testing ».

Voici ci-dessous un résumé de ses diverses critiques :

  • La plupart des développeurs pratiquant le TDD vous font ressentir que votre code est forcément sale si vous n’utilisez pas cette méthode.
  • Conduire votre design sous l’axe des Test Unitaires n’est pas une bonne idée.
  • La notion du TDD préconisant que les tests doivent être rapide est illusoire.
  • Faire une totale confiance au TDD peut amener à négliger voire totalement oublier les tests globaux du système.
  • Se focaliser sur les tests unitaire n’aide pas à créer un bon système.
  • Avoir un taux de couverture des test à 100% est stupide.
  • Les développeurs veulent que le logiciel soit une science, mais ça ne l’est pas. C’est plus une écriture créative.
  • La réussite d’un logiciel ne repose pas (uniquement) sur l’ingénierie.
  • Une écriture claire et concise vaut mieux qu’une écriture alambiquée
  • La clarté est très importante. Elle l’est tellement qu’elle devrait être l’objectif n°1, non pas les tests de couverture ou la rapidité des tests.
  • Devenir un bon développeur est aussi dur que devenir un bon écrivain.
  • Tout comme pour l’écriture, le moyen de devenir un bon développeur est de développer beaucoup de logiciel, analyser beaucoup de logiciel, et viser le plus de clarté possible.

 

Bien entendu de nombreuses réponses sont allées à l’encontre des dires de David Heinemeier Hansson .

 

Sources : Python Testing, Blog Octo, Igm, Institut Agile, Wikipedia

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *