Bonjour,

J'ai eu l'occasion de reflechir sur BDD ces derniers temps et voici ce que
j'en ai conclu.

On est tous d'accord que BDD permet d'exprimer des tests avec un focus plus
fonctionnel. Et dans les messages de ce thread, on sent qu'il y a un
recouvrement avec les outils TDR (Test-Driven Requirements) a la FIT,
FitNesse, GreenPepper, Concordion & co. Je suis aussi de cet avis.

Je pense que vous serez avec moi en disant que BDD et TDR permettent de se
concentrer sur les besoins client (le *bon code* par analogie avec le *code
bon*, deja adresse par TDD), mais avec un outilllage oriente developpeur
pour BDD et un outillage oriente analyste fonctionnel pour TDR (a noter que
je ne suis pas d'accord pour dire que le Product Owner pourrait ecrire ses
tests client avec BDD).

Du coup, TDR me parait etre un outil adapte quand les analystes sont bien
integres avec les developpeurs, par exemple en faisant partie de l'equipe
technique, ou au moins en etant presents regulierement en cours d'iteration
pour le Sprint Planning + des conversations pour detailler les User Stories.
TDR permet de tomber sur un accord concernant les fonctionnalites a
developper, sans avoir a prealable plus qu'une User Story pour decrire le
besoin. TDR est donc principalement un outil de communication entre des
personnes tres techos et des personnes plutot metier.
cf. http://jamesshore.com/Blog/Five-Ways-to-Misuse-Fit.html pour plus de
discussion sur cet aspect.

Par contre, j'estime que BDD est un outil adapte quand les developpeurs
recoivent les specs d'une equipe MOA exterieure, rediges peut-etre plusieurs
iterations avant. Ca n'est pas une situation ideale, mais cela arrive
encore. Dans ce cas, les developpeurs n'ont pas interet a perdre leur temps
avec l'utilisation d'un outil comme FIT qui n'est tout de meme pas tres
efficace de leur point de vue.
BDD est excellent aussi quand la totalite de l'equipe est composee de
personnes tres techniques, a meme de lire le code source tous les jours sur
leur poste. Je pense typiquement a des committers sur un projet open-source
(vous connaissez beaucoup d'analystes fonctionnels sur un projet OSS?) mais
aussi a des equipes dans une start-up qui ont une excellente comprehension
de ce qu'elles doivent developper.

Derniere chose: comme certains autres outils, il est possible que BDD
augmente la cohesion a l'interieur de l'equipe, tout en creant des defenses
par rapport au monde exterieur qui n'est pas aussi 'jelled'. Du coup, cela
peut limiter les gains futurs lies a l'integration de personnes
non-techniques.

Je serais interesse par des critiques sur cette analyse...

Eric

2008/6/3 Cédric Girard <cedricgirard@...>:

> Le 03/06/08, Camille <cam_bloch@... <cam_bloch%40yahoo.fr>> a écrit
> :
>
> > De mon point de vue, BDD apporte une autre dimension au TDD car ca permet
> de décrire des actions de plus haut niveau que des tests de code. Ainsi, le
> Product Owner (désolé, je fais plus du scrum que du XP ;-) ) peut les écrire
> lui même. Dans mon équipe, on a même commencer à étudier Concordion pour
> générer du test auto à partir de" BDD like".
>
> Mon questionnement personnel sur BDD est de savoir si c'est juste une
> manière plus concise et "haut niveau" d'écrire les mêmes tests, ou
> s'il y a quelque chose d'autre que je n'ai pas vu.
>
> > Et enfin, le dernier avantage du BDD dans notre projet, c'est qu'on a un
> historique de code de 7 ans sans test auto. et le BDD rentre plus facilement
> pour écrire les "acceptance tests" des nouvelles User Stories
>
> Meilleure prise en main par l'équipe? Je serai intéressé par un
> développement.
>
> Cordialement
> Cédric
>
>


[Les parties de ce message comportant autre chose que du texte seul ont été
supprimées]