TDD : Test driven development

Il ne semble pas naturel de commencer son développement informatique par les tests. Comment est-ce possible vu que l’on n’a rien à tester ? N’est-ce pas mettre la charrue avant les bœufs ?

On pourrait le penser à première vue, mais il en est autrement. L’approche TDD (issue de la méthode XP pour eXtreme Programming) consiste à dire que la façon dont nous allons écrire nos tests va piloter la manière dont nous allons développer notre fonctionnalité. C’est une forme originale qui a pour but premier d’aider aux spécifications. La fonctionnalité est vue comme le moyen de prouver que celle-ci répond à tous les cas de tests que l’on a imaginé en amont. C’est une approche itérative. Cette méthode est particulièrement efficace, car elle s’intègre parfaitement avec un CI-CD. De plus, pris dans ce sens, on a plus facilement la garantie que nos développements vont passer les tests puisqu’on implémente la fonctionnalité pour répondre à cet objectif précis.

Dans l’idéal, une personne va écrire les tests et une autre va les implémenter (notion de pilote et co-pilote) mais il n’est pas rare qu’une seule et même personne fasse les deux.

Le développeur commence à écrire un test (une coquille vide) qui va donc échouer lors de son premier...

Pour consulter la suite, découvrez le livre suivant :
couv_EPDEVOPIC.png
60-signet.svg
En version papier
20-ecran_lettre.svg
En version numérique
41-logo_abonnement.svg
En illimité avec l'abonnement ENI
130-boutique.svg
Sur la boutique officielle ENI
Précédent
Introduction
Suivant
Exemple de mise en œuvre