Behaviour Driven Development Is About Conversation Not Tooling

| by Jan Stenberg Follow 26 Followers on Apr 24, 2014. Estimated reading time: 1 minute |

A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.

The single most important of Behaviour-Driven Development (BDD) is the conversation, not the tooling, Liz Koegh states in a presentation about 10 years of doing BDD at a recent Cucumber conference.
Liz, an independent agile coach and contributor to e.g. JBehave, believes we have made some big mistakes during the years of practicing BDD, but she is quite excited about our current understanding and some of the developments that has happened over the last few years.

Dan North in 2003 first came up with the idea of BDD by defining it as a bit like TDD but using the word "should" instead of "test" to describe how a system should behave. BDD was then formally introduced 2006 by Dan after finding that talking about behaviour, particularly about examples, was more useful than talking about tests.

One mistake Liz made during the early years was trying to replace the word "should" with "must" or "will" to get closer to a contract and a lot of people agreed, but Dan emphasized that should is preferred since it encourages questioning and conversations.

Another mistake increasingly made by the community using BDD was people claiming to do BDD but without any conversations and talking about BDD tests when the purpose was to move away from the word test, instead asking stakeholders and domain experts about examples on behaviour or scenarios.
Liz emphasizes the need for people to go back to the conversations. She has found that the focus on test automation actually slows people down by writing too many scenarios and focusing more on tooling than on conversations, the message being to step away from the tools, BDD will not work unless you have the conversations to explore the behaviour of a system.

A new concept Liz finds very interesting is Cynefin as a way of estimating complexity, focusing on scenarios with a lot of uncertainty for the business and using BDD in these areas to spot the outcomes.

Liz ends her presentation with the main purpose of BDD:

BDD is about writing software that matters (using examples!)

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread


Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you