Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Why You Should Care About Behaviour-Driven Development

Why You Should Care About Behaviour-Driven Development

This item in japanese


Agile has helped us move away from creating upfront precise requirements into working with smaller pieces of ideas, but we still have a huge amount of waste with lots of discovery and misunderstandings late in the process, even in short sprints, Matt Wynne states in a recent overview of Behaviour-Driven Development, BDD.
A key problem BDD is meant to improve is the communication between people working in the problem domain and in the solution domain, Matt, lead developer for Cucumber, (an open source tool for BDD), further explains. BDD is meant to create and grow a common area of understanding between the two domains, to create a common language, an ubiquitous language as defined in Domain-Driven Design, DDD.

User Stories is an agile tool helping us describe requested functionality. To better understand these stories before turning them into working features, BDD uses concrete examples to explore how we would use the described functionality. They are also a cheap way to find edge cases in an early stage instead of discovering these later on when it’s much more expensive to fix them.
An advantage with BDD focusing on examples to explore the problem domain is also that everyone can get involved, from users and stakeholders to developers and testers; examples are not technical, basically all you need is pen and paper or something similar.

When looking into the solution domain, Matts' experience is that teams, as a project evolves, often finds it harder and harder to introduce a change into the codebase. Matt compares a codebase with a kitchen; a well-organised clean kitchen makes it easier to produce high-quality food. To keep a kitchen clean means constantly washing up, putting things away etc., and a professional working environment needs to have the same strategy. In a codebase the equivalent to washing up in a kitchen is refactoring; changing the design without changing its behaviour. The codebase gets a little bit more organised, a little bit easier to understand and change.
To ensure that behaviour is not changed during refactoring automated tests are needed, e.g. by using Test-Driven Development, TDD, and BDD which both use examples to clarify requirements.

You won't stay agile without clean code

BDD was developed around 2006 by Dan North who has written both an introduction and about stories from a BDD perspective.
Specification by Example is a way of defining requirements closely related to BDD.

Cucumber is an open source tool for Behaviour Driven development, BDD, currently for nine programming languages, including JVM-based languages. A new version, Cucumber Pro for the Enterprise was recently released.

Rate this Article


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.

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

Community comments

  • When to embrace Behaviour Driven Development (BDD)?

    by Ranjith Tharayil,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Behaviour Driven Development (BDD) is a collaborative and disciplined technique to help us build the right product. In the last decade BDD has had her own bit of glory and criticism. Many teams in the recent past have reaped benefits from this technical practice, while some teams complain that are yet to find any value. This article focuses on answering two questions; Why BDD might not always be the right choice? What are the ideal conditions when teams should adopt it? (

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

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