Would BDD change the way you TDD?

[Tim Cooke]

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

[John Smart]

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]

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?

[John Smart]

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]

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]

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