La taverne du testeur

TDD: Test Driven Development

Définition

Le TDD (Test Driven Developement) est, comme son nom l’indique, une méthode de développement. Elle consiste à écrire les tests avant d’écrire le code. Le but est donc pour l’équipe projet de développer un logiciel construit par la validation de tests plutôt qu’un logiciel construit par le suivi des spécifications. Le TDD est donc une méthode de travail différente du BDD (Behaviour Driven Developement) où le développeur développe en fonction des spécifications fonctionnelles puis écrit les cas de tests unitaires, les autres niveaux de tests étant exécutés ultérieurement.

Fonctionnement du TDD

Le TDD fonctionne par cycle.

TDD

·        On écrit d’abord un test.

·        On l’exécute puis on valide que le test est en échec car la fonctionnalité n’a pas été implémentée. Si le cas de test est en succès, alors, s’il est mal été écrit il doit être remanié, sinon la fonctionnalité est déjà implémentée et aucun développement n’est nécessaire.

·        On développe la fonctionnalité jusqu’à ce que le test soit en succès.

·        On « nettoie » le code, pour garder un code propre, de bonne qualité et facilement maintenable.

·        On ré-exécute les tests (celui du cycle et les anciens tests) et s’assure que l’ensemble des tests est encore en succès.

·        On écrit un nouveau test en échec.

Le TDD repose sur l’écriture des tests à mettre en succès. On s’aperçoit également que c’est une méthode incrémentale demandant de nombreuses exécutions. L’automatisation des tests doit donc être envisagée en TDD (comme en SCRUM).

On parle souvent de RGR (Red Green Refactor) lorsque l’on parle du TDD. Red correspond à un cas en échec, Green à un cas en succès et Refactor au nettoyage du code pour améliorer la qualité. Cela est un bon résumé de la méthode TDD.

TDD tests unitaires

Lorsque l’on parle de TDD on parle généralement de TDD pour les tests unitaires. Avec la méthode du BDD les développeurs écrivent leur code puis les tests unitaires. Dans le cas des TDD c’est le contraire, il écrit les tests avant puis doit écrire son code afin de valider ces tests.

Les TDD sur les tests unitaires sont assez faciles à implémenter, en effet, ces tests étant écrit (mais aussi généralement exécutés et maintenus) par les développeurs, seuls ces derniers doivent s’habituer à cette nouvelle méthode.

ATDD (Acceptance TDD)

Le principe ici est d’appliquer la méthode du TDD aux tests d’acceptance (aussi appelés tests métiers). Le cycle reste le même par contre les métiers fonctionnels (MOA, recette…) et techniques (développeurs…) doivent travailler sur ces tests. Cela oblige donc une adaptation au TDD par un plus grand nombre de personnes et encourage également fortement la communication entre ces équipes.

Pourquoi utiliser le TDD ?

Comme pour chaque méthode, le TDD a ses points forts et ses points faibles. Le TDD vise à assurer une bonne qualité du produit de par la certitude que les cas de tests existent et sont exécutés mais aussi par le « nettoyage » récurent du code. Cette méthode incrémentale s’adapte parfaitement aux autres méthodes de travail incrémentales (comme le SCRUM) et aux projets à fort potentiel d’automatisation.

Le TDD est généralement bien perçu par les développeurs, ces derniers voyant par la validation d’un test la valorisation (et un accomplissement) de leur travail alors qu’en BDD, l’écriture du cas de tests arrivant après le développement, elle est souvent perçue comme une corvée.

Le TDD (pour les ATDD) encourage la communication et donc permet d’éviter de mauvaises interprétations.

Enfin, effectuer régulièrement les cas de test permet de détecter plus tôt les bugs, ils sont donc moins cher à corriger.

Sources :

TDD (FR) : http://igm.univ-mlv.fr/~dr/XPOSE2009/TDD/pagesHTML/PresentationTDD.html

TDD (GB et plus complet): http://agiledata.org/essays/tdd.html

ATDD : http://blog.neoxia.com/l%E2%80%99a-t-d-d-une-approche-efficace-de-developpement-logiciel/

6 réponses

  1. Bonjour, le BDD fait avec la méthode double loop TDD permet de faire du TDD pendant l’écriture de la « glue » des tests cucumber, en quasi simultané.

    1. Bonjour,
      non TDD ne peut pas s’appliquer sur un code déjà écrit. Le principe même de TDD est d’écrire les tests afin d’être guidés par ces derniers dans le développement. Le code (ou les changements qui lui seront affectés) ne peut donc pas être écrit avant

  2. D’accord, merci, cela fait sens dans une approche pour le nouveau code.

    Ma question portait plus sur l’utilisation du terme de « Test Driven Development » comme une approche « Test-first » pour du code dépourvu de tests unitaires.

Laisser un commentaire

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

Outils

Outil de test: concevez vos tests avec Yest

Yest en Bref Yest est un outil de conception de test qui se sert des schémas afin de rendre plus compréhensibles les scénarios. Cette modélisation graphique n’a pas seulement pour but de concevoir les tests. Yest peut également être utilisé pour faire de l’ATDD visuel et donc améliorer la communication

Lire la suite »
Avenir

Perspectives 2024 pour les testeurs

Une nouvelle année commence et avec elle l’exercice complexe de prédiction des évolutions! Dans cet article je vais aborder quelques points qui devraient, selon moi, animer l’année 2024 (et les suivantes des testeurs). L’IA en croissance exponentielle L’année 2023 a apporté pas mal de changements, pas dans les pratiques, mais

Lire la suite »
Agilité

Les Tests Exploratoires, Une obligation dans l’agilité ??

Introduction : Les Tests Exploratoires sont devenus un incontournable des méthodes Agiles pour plusieurs raisons : C’est une méthode complémentaires aux Tests classiques, qui ne perturbe donc pas le déroulement d’un ‘Sprint’ ; Elle correspond aux principes agiles car elle ne demande pas une spécification lourde des Tests, en cela elle favorise le

Lire la suite »