BDD in a Nutshell

On Friday I was talking to Katie, she works in a department where teams are trying to apply Behaviour-Driven Development (BDD). She hasn't been on Matt Wynne's BDD training workshop yet and is looking for some background reading to explain what it's all about. So I've put together this blog to explain what BDD is and pull together some links for further reading.

What is BDD?

The B in BDD stands for Behaviour, the desired behaviour of the software to be developed. The DD part stands for Driven-Development. BDD is an approach for building a shared understanding on what software to build by working through examples.

I've drawn this basic sketch to illustrate the basic idea.

BDD is pretty simple, describe what you want the system to do by talking through example behaviour.Work from the outside-in to implement those behaviours using the examples to validate you're what you're building.

You don't have to bring the whole team together but it helps to get different perspectives to flesh out the examples. The customer (who may be a Scrum Product Owner) describes what they want and the developers ask questions to flesh out enough detail about the behaviour to be able to implement it. If you have business analyst or quality assurance specialists then they can help tease out details of different scenarios.

Like TDD but more

The examples are often turned into automated tests and BDD practice follows the same basic idea as Acceptance Test-Driven Development, where acceptance tests are elaborated for each user story and automated as the software is built. Matt Wynne says "BDD is basically TDD done properly."
 
BDD is more than TDD because it focuses on collaborating with business people. Dan North, who originated the BDD moniker, noticed that business people switched off in conversations about "tests" as these seem to be too technical. He hoped that framing conversations about "behaviours" would be a way to engage the whole team.

Ubiquitous Language

To make sure that the whole team understand what's wanted, we describe the behaviour in non-technical language. We're careful to use names that reflect the ubiquitous language used by business people, a basic principles of Domain-Driven Design as explained by Eric Evans and summarised in Domain-Driven Design Quickly.

Ultimately BDD is about building a shared understanding, you're doing BDD wrong if the only people who read the examples are the developers. I have seem this implementation in a few places, see pic below. BDD is much more than a way of automating tests and if that's all you have in mind then a unit-test framework might given you a faster suite of tests.

Inspirations of BDD

BDD was originated by practitioners of eXtreme Programming (XP) who were looking for a way to involve all perspectives (including BA and QA) in conversations about what to build.

Much credit has to go to Ward Cunningham, inventor of the wiki and many XP practices, who in 2003 developed a testing framework called FIT that enabled business people to specify tests in tables using spreadsheets. Around the same time, Brian Marick, was writing about expressing tests as examples.

Tooling to support BDD evolved initially in JBehave with Liz Keogh as an active contributor and later with Cucumber.

What BDD is not

BDD is about figuring out what to build that helps flesh out behaviour. BDD isn't an Agile framework or project management approach. Teams using Scrum or Kanban with BDD will need to figure out what to put in their backlogs and boards for planning purposes. You might want to measure the number of BDD scenarios delivered instead of velocity but often these scenarios are too fine-grain for release planning purposes.

Further Reading

Websites:

• Wikipedia

• http://behaviour-driven.org/

• http://dannorth.net/introducing-bdd/

Books:

• "The Cucumber Book:Behaviour-Driven Development for Testers and Developers" Matt Wynne and Aslak Hellesøy

• "Specification By Example: How Successful Teams Deliver the Right Software" by Gojko Adzic

• "Fit for Developing Software: Framework for Integrated Tests" by Rick Mugridge and Ward Cunningham

• "The RSpec Book: Behaviour-Driven Development with RSpec, Cucumber, and Friends" by David Chelimsky, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, Dan North

Articles:

• Virtual Panel: Specification by Example, Executable Specifications, Scenarios and Feature Injection
• The Three Amigos

Please add comments to point to further resources. Thanks!

Comments

[Markus Gärtner]

My upcoming book ATDD by example will have an example on BDD-style tests using Cucumber as well as a section on parts of the theory behind BDD, though it is more focused on ATDD, but I found BDD belongs in that book, too.

[George Dinwiddie]

My article on the Three Amigos, published in Better Software and on the TechWell website (http://manage.techwell.com/articles/weekly/three-amigos), describes what BDD might look like in practice.

[Matt Wynne]

Great post Rachel!

Another link you could include in there is this 'virtual panel' discussion where Dan, Liz, Gojko and answered some questions about BDD. I think there's a lot of really useful background in it:

http://www.infoq.com/articles/virtual-panel-bdd

[Rachel Davies]

Thanks for the links. I've added those to the bottom of the blog post now.

[Aditya]

http://oredev.org/tmp/videos-2011

To watch videos , please see this link

[Lance Kind]

Your stick figures ROCK! Keep it up! I find that illustrating using simple cartoons requires focused and tight communication much as twitter requires us to organize our thoughts to the BONE to a point across.

Nice! Nice!