BDD – TDD done well?

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.

This entry was posted in bdd. Bookmark the permalink.

2 Responses to BDD – TDD done well?

  1. adam_sroka says:

    The idea that BDD is the same as TDD done well was originally expressed by Dave Astels in an article that he published on his blog a few years ago (About the same time that rSpec was released.)

    I don’t think the statement itself has much value outside of its original context. It is a simplistic comparison made to illustrate a point (That BDD is not something entirely new, nor is TDD “wrong”.)

    Many of us see BDD as an evolution of TDD. It is worth noting that TDD is an evolution of XP, where test-first, simple design, and refactoring were originally listed as separate practices. It is now well understood in the XP community that all these things are integral to TDD.

    The description of BDD above is no different. It integrates the notion that stories have criteria for acceptance that are defined by the customer and can be specified in automated way. It takes this idea, which itself is not new to XP, and integrates it with the other ideas that are part of TDD. It also integrates the idea of top-down design, which is essential for YAGNI, though not all who do TDD do it in a top-down fashion.

    So, IMO, BDD is a new way of talking about TDD, and it is also a further refinement of how existing XP practices integrate into a working whole.

  2. sirenian says:

    That’s a great way to put it. Thanks for filling me in on the history, too.

Comments are closed.