Someone on the XP thread suggested, “BDD is just TDD done well with different words.”

Here’s my take.

An application is the end-product, and the value of the application is delivered through its behaviour, as perceived through its user interface.

BDD uses descriptions of behaviour and executable examples (or exemplars; examples carefully chosen to illustrate a particular behaviour). These exemplars, whether in code or plain English, are an aid to communication, to driving a clean, simple design, to understanding the domain, to focusing on and delivering the business value, and to giving everyone involved clarity and confidence that the value is being delivered.

Is doing the above merely ‘doing TDD well’? Maybe it is, but I think that the words do help to change the focus; also, my experience (amongst others) is that some people who struggle to do TDD well find BDD relatively easy.

Here are some of the practices I use in BDD.

A story is a narrative from a customer in a particular role, describing a particular feature and a value that will be delivered through the use of that feature. Scenarios associated with the story will be executable, either manually or through automation, once the feature delivers the value.

(This isn’t a practice; it’s just how stories and scenarios work.)

Making the scenarios and examples executable allows us to know when the value has been delivered, at each level of code. Maintaining those examples allows us to continue to have that certainty as other features are developed.

(This isn’t a practice; it’s just how good tests work. But without using the word ‘test’.)

Each level of code in the application delivers value to some other piece of code, through its own behaviour and its own interface (which could just be the externally visible methods, or an actual java-style Interface). Eventually the sum of those values is delivered to the user interface, which delivers the value to the customer.

(This isn’t a practice; it’s just how software works.)

Describing these stories and behaviours in English allows more people to understand the code and talk about it than otherwise might. For developers, it encourages the use of English in place of Geek. This aids communication.

Driving behaviour from the user interface downwards, and focusing on each unit of code, its responsibility to deliver its value to another, and its ability to use other code to deliver value to itself, minimises non-valuable code and allows developers to split responsibilities easily. This results in a clean, simple design.

Capturing common contexts, events and outcomes, and using these as part of the (coded) domain language, helps us to understand the domain.

Coding the story and scenarios (exemplars at the user interface level, automated at the closest possible level to that interface) helps us focus on, and deliver, the desired value.

Using English for executable scenarios and examples means that everyone, including the customer, can understand which values are delivered, which have been lost (either deliberately or otherwise), and which are yet to come. This helps to give everyone clarity and confidence.

(These are some things I practice as part of BDD.)

I believe this is more than just ‘doing TDD well’. I think it’s ‘doing TDD and a number of other practices related to professional software development well’. The five practices above might conceivably be done in addition to TDD, but they’re not part of any definition of TDD I’ve seen.