De quoi s'agit-il?

Sur le modèle du développement par les tests, cette pratique ajoute au développement de tests de recette automatisés une contrainte supplémentaire: ceux-ci doivent être réalisés en amont des développements correspondants.

L'idéal recherché (mais atteint relativement rarement) consiste à ce que le responsable du produit, client ou expert fonctionnel soit en mesure de définir de nouvelles fonctionnalités sous la forme de tests de recette, sans que l'intervention des développeurs soit nécessaire.

On l'appelle également...

Couramment désignée par l'acronyme ATDD ("acceptance test driven development"), plus rarement STDD ("storytest driven development").

Erreurs courantes

Plus encore que la simple utilisation de tests de recette automatisés, cette pratique est liée à des outils tels que Fit/FitNesse, Cucumber, etc.

Il convient par conséquent d'être d'autant plus vigilant à ce que le choix des outils ne se fasse pas au détriment de la facilité, pour les responsables produit, à dialoguer avec les développeurs à propos de la définition des exigences.

Origines

• Kent Beck aborde brièvement cette pratique dans son livre "Test Driven Development: By Example" mais la juge peu praticable (2003)

• c'est à partir de 2003-2004 et sous l'impulsion de Fit/FitNesse que cette pratique fait son chemin malgré les objections soulevées par Beck

Quels bénéfices en attendre?

• de même que le développement par les tests oblige à concevoir les applications pour être facilement testable au niveau unitaire, le développement par les tests client oblige à créer des interfaces spécifiques pour le test fonctionnel; il est généralement conseillé de ne pas tester directement à travers l'IHM mais de fournir une couche dédiée au test applicatif par exemple