Développement piloté par les tests:
revue du TDD

Publié le 19 février 2020 par Adrien Saint

Principe

Le TDD (test-driven development) est une méthode de développement logiciel mise sur papier par Kent Benck en 2003 suivant le principe de « Ne jamais écrire une ligne de code à moins d’avoir un test unitaire échoué ».

Cette méthode a aussi pour but fondamental « d’éliminer la duplication ».

Pour la petite histoire, Kent Benck est aussi le créateur de l’extrême programming et est un des premiers signataires du Manifeste Agile.
Avec le TDD, le test est donc rédigé avant l’écriture du code source.

.

Ce que résout le TDD

Les tests sont fondamentaux dans le contrôle qualité de ce qui est développé. Malgré ce caractère crucial, ils sont souvent réalisés manuellement et sont à la fois chronophage et coûteux.
Le TDD a été imaginé afin d’optimiser la qualité du code et d’avoir du code qui correspond parfaitement aux besoins exprimés.
Autre élément adressé par l’utilisation de cette approche: la complexité d’une pléthore de tests, qui augmente au fur et à mesure du projet.

Le TDD a pour vocation de minimiser le recours aux test manuels et améliore particulièrement le fait qu’ils soient :

  • fastidieux et coûteux
  • exponentiels (en nombre de tests)
  • limités, car l’ensemble de tous les tests est joué de façon moins fréquente

D’un autre côté, les tests unitaires (pass ou fail sur un module développé) peuvent être facilement automatisés et répétés. En étant intégrés dès le début du projet, les erreurs peuvent être détectées au plus tôt et assurer une meilleure qualité du code au fur et à mesure du développement.

.

Le cycle du Développement en TDD

1. Chaque nouvelle fonctionnalité commence avec l’écriture d’un test. Il faut définir la fonction et ses améliorations de façon succincte. Pour cela le développeur doit clairement comprendre la fonctionnalité et ses demandes. Il est recommandé d’utiliser des use cases et des users stories pour les fonctionnalités et les conditions. Cela permet de porter son attention uniquement sur la fonctionnalité avant d’écrire du code.

2. Ensuite le développeur peut lancer tous les tests et voir ceux qui échouent. Le nouveau test, sans code pour le faire fonctionner, doit normalement échouer par défaut.

3. L’étape suivante consiste à écrire le code, puis de ;

4. Lancer tous les tests. Lors de cette étape, tous les tests doivent être au vert, s’ils ne le sont pas, il faut ajuster le code et relancer les tests jusqu’à ce qu’ils soient concluants.

5. Lors de la refactorisation, il faut enlever toute la duplication possible. Les objets, classes, modules, variables et les méthodes doivent clairement représenter le but à obtenir, le tout de façon concise.

La réitération automatisée des prochains tests permet d’assurer la qualité tout au long du projet. Si un test échoue, il faut alors l’étudier et identifier l’ajustement à apporter afin que les éventuelles interdépendances soient fonctionnelles et que les tests soient de nouveau un succès.

.

Avantages du TDD

  • Écrire les tests avant de développer permet de s’assurer que toutes les fonctionnalités sont testées.
  • Cela permet d’avoir une compréhension profonde de la fonctionnalité et du produit.
  • Permet d’être concentré sur ce que l’on fait
  • Cela accroît la maintenabilité et la qualité.
  • Quand on code d’abord et que la fonctionnalité répond aux exigences nous avons tendance à nous attaquer directement à la prochaine avant de repenser à notre code, sa qualité, sa maintenabilité, sa ré-usabilité…
  • Cela réduit le temps de débogage.
  • Il est beaucoup plus facile de savoir d’où viennent les erreurs lorsqu’un test passe au rouge.
  • Les tests deviennent une sorte de documentation vivante
  • Une étude a montré que les développeurs utilisant le TDD étaient plus productifs
  • Permet d’éviter les « anti-patterns »
  • le TDD peut aussi orienter l’architecture et le design
  • Permet une évolution étape par étape
  • Pas de code écrit inutilement

.

Les limites du TDD

La méthodologie TDD ne permet pas de tester une situation lors de laquelle l’ensemble de toutes les fonctionnalités est nécessaire à un succès ou un échec car elle porte sur une batterie de tests à plus petite échelle.

Dans la plupart des cas, le développeur écrit lui/elle-même ses tests. Il est donc essentiel que le client transmette des informations claires quant aux fonctionnalités attendues et aux tests à mettre en place.

Certains modules doivent modifier leur test avant de pouvoir avoir de nouveaux comportements, ce qui peut rendre certains composants moins flexibles que dans d’autres fonctionnements.

.

Le ATDD: Acceptance Test-Driven Development

Très proche du TDD, tant par le nom qu’en pratique, l’ATDD est notamment largement compatible avec un projet Agile.
L’ATDD centre ses tests sur l’utilisateur. Ainsi les tests sont écrits en collaboration directe avec l’utilisateur et le client, et porte sur l’aspect fonctionnel plutôt que l’aspect technique.

.

Conclusion

Le TDD est une approche très utile lors du développement logiciel. Il met un accent fort sur le contrôle continu d’une qualité planifiée.

Lorsqu’un projet débute en TDD, un gain de temps sera engendré. Plus le projet est long et complexe plus le gain sera important. En effet, les efforts de mise en place initiale des tests rallonge le kick off mais le temps investit en début de projet permet des économies de temps pendant le projet et en fin de projet car le code est meilleur et les tests pointent vers les problèmes de façon plus précise.

L’approche permet de livrer une nouvelle version d’un logiciel avec un haut niveau de confiance dans la qualité des livrables, confiance justifiée par la couverture et la pertinence des tests à sa construction.

.

sources:

 

SUR LE MÊME
THèME

restez
informés

Abonnez-vous à notre newsletter pour être certain d’avoir un autre regard sur le numérique, vu dans haut, en panoramique !