File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Design and the fly likes Would BDD change the way you TDD? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Design
Bookmark "Would BDD change the way you TDD?" Watch "Would BDD change the way you TDD?" New topic
Author

Would BDD change the way you TDD?

Tim Cooke
Bartender

Joined: Mar 28, 2008
Posts: 937
    
  44

Hi John,

I am a Software Engineer. My broad process for developing a product feature is to write an end-to-end system test to specify the desired external behaviour (requirements) of the system, and then employ TDD to discover and realise that behaviour. Beyond this immediate scope my company has fully invested in Agile as their full lifecycle of building software products.

I have read through the sample chapter and for the most part it sounds very similar to the way we build software today, but we don't call it BDD.

Is there some key difference/concept/approach that BDD aims to address that teams may not be achieving with a more "traditional" Agile setup?

And the same question again from a Developers point of view. Would BDD alter my current practice of TDD (as Kent Beck described a decade ago in TDD by Example)?

Many Thanks
Tim


Tim Driven Development
John Smart
Author
Ranch Hand

Joined: Aug 06, 2013
Posts: 33
    
    5
Hi Tim,

It's good you here you are practicing TDD. BDD is an evolution of the concept of TDD as described by Kent Beck, and at the coding level, TDD can be practiced in a very similar way to BDD. However the emphasis is a little different, and the BDD vocabulary and approach changes the way you think about designing the code. BDD tends to be easier to learn than TDD. BDD strongly encourages developers to think about what their code should do, and why, with regards to the underlying business requirements, and even to provoke questions and clarifications about the requirements ("Sales tax of zero should not be allowed" - shouldn't it?). BDD has a stronger emphasis on living documentation, executable specifications and worked examples of code: while this is present in TDD, it is not always practiced as well as it could be. In BDD, you actively structure your tests (or "executable specifications") to read like a low-level specifications document. The most obvious change with regards to TDD is a change in vocabulary, e.g. using the word "should" instead of "test", which places the emphasis on the expected outcomes, rather than the method under test (shouldTransferFundsIntoDestinationAccount() instead of testTransfer()).

BDD embodies many core Agile principles like a strong emphasis on collaboration and communication, and getting fast feedback. But the BDD approach adds a few techniques and tools that make these principles easier to apply - many of these techniques are also used elsewhere, and are not exclusive to BDD.
Vish Shukla
Ranch Hand

Joined: Oct 12, 2008
Posts: 111
BDD looks like a very good tool for Requirement elicitation and Requirement specification. Does BDD encourage involvement of business analyst or customer or even BDD tests to be developed only by business analysts, if you have such dedicated roles in the company?


Thanks & Regards,
Vishal S Shukla (SCJP 93%, SCWCD 94%, SCBCD 100%)
John Smart
Author
Ranch Hand

Joined: Aug 06, 2013
Posts: 33
    
    5
Yes, BDD is a strongly collaborative practice. At the requirements elicitation level, BDD strongly encourages (even mandates) ongoing conversations and exchanges between the customer and the BA, and also other team members such as QA and devs.
Vish Shukla
Ranch Hand

Joined: Oct 12, 2008
Posts: 111
So what should be the ideal way one could start of the project, in BDD way? When you are not even aware about what all components your system would have, what should be the very first step to derive the high level design & even component level design out of the requirements.
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
Vish Shukla wrote:So what should be the ideal way one could start of the project, in BDD way? When you are not even aware about what all components your system would have, what should be the very first step to derive the high level design & even component level design out of the requirements.

Vish,
From what I've read and tried, BDD helps identify the components you'll need, and can drive the TDD portion of the project. By focusing on *what* you want the system to do first, you can often see the underlying structure needed to make that happen. For me, it's definitely a top-down approach - pushing the unknown down to the next layer until it becomes obvious what's needed to fulfill the requirements.

I hope this helps,
Burk


SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Would BDD change the way you TDD?