From: Phlip <phlip2005@...>
Date: 2008-08-17T00:47:01+09:00
Subject: Re: BDD and TDD - What are they for?

Eleanor McHugh wrote:

>> Figuring out how to say an internal detail in terms a client can  
>> understand is often brain-wrenching. As developers, our brains are  
>> prepped with developer terms. The B in BDD stands for "Behavior the  
>> client has requested"...
> 
> Which of course presupposes there is a clear and direct transformation  
> between what the client believes they want, what they actually want,  
> what they should actually get (which is not always the same thing) and  
> how these can be represented in software given whatever other  
> arbitrary requirements apply. I'm too much of a cynic (i.e. have  
> worked on too many complex projects with multiple stake-holders) to be  
> convinced of this fact, but I definitely wouldn't discourage anyone  
> else from giving it a go as different tools work for different people :)

That's why you don't T- or BDD in a vacuum. Your "goal donor" should review your 
features, and their tests, in tiny little increments, every couple of days, with 
a new release and a new requirements list each week.

The "goal donor" writes a user story saying "if you fail to log in six times, 
put the user's IP in a killfile for one hour", then you should have a spec that 
says the same thing. Doing exactly what the client says would be "malicious 
compliance", if letting them follow up weren't so easy.

-- 
   Phlip