All You Need to Know About Behaviour-Driven Software Development

Behaviour driven software development is an approach in which a team agrees what a system should do by writing concrete examples of the intended behaviour before the code is written. A fuller treatment is on the definition page; this is the short version, and it assumes no particular technical background.

What behaviour driven development is

The examples are written in language shared by everyone with a stake in the work, and they are precise enough to be run automatically. Because they can be run, they cannot quietly become inaccurate: when the behaviour changes and the example does not, the example fails.

That property is what separates the approach from ordinary written requirements. A specification document describes intent at the moment it is written and then drifts, because nothing forces it to keep up. An executable example drifts too, but noisily. The build goes red, somebody has to decide whether the code or the example is wrong, and the decision gets made deliberately instead of by neglect.

The practical unit is a scenario: a starting situation, an action, and the outcome that should follow. Teams write these together rather than handing them from one role to the next, which is where most of the benefit comes from. The conversation needed to agree an example tends to surface the disagreement that a requirements document would have hidden until much later.

History and development

The term was introduced by Dan North in the mid-2000s and set out in his 2006 articleIntroducing BDD. It grew out of teaching test driven development, where the word "test" was found to cause most of the resistance the practice met. Developers heard a request to write more tests, when the intended request was to think about behaviour before implementation. Changing the vocabulary changed how the practice landed.

A definition North gave in 2009 is still the one most often quoted: a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation agile methodology describing a cycle of interactions with well-defined outputs. It is a dense sentence, and the part that matters most is "outside-in": start from the behaviour someone outside the system wants, then work inwards to the code, rather than building components and hoping they compose into something useful.

From there the idea spread through tooling. Frameworks appeared in Ruby, then Java, .NET, Python and JavaScript, most of them sharing a common notation so that the examples read the same whatever language runs them. The Wikipedia article on behavior-driven development gives a broader summary of that spread, and the current landscape is set out under BDD frameworks by language.

Basic principles

Three, as originally stated. Business and technology should describe the same system in the same way. Any system should have an identified, verifiable value to the business. And up-front analysis, design and planning all have a diminishing return, so enough is enough.

The first principle is the one that does the work. When the business describes a feature in one vocabulary and the code uses another, every conversation carries a translation step, and translation is where requirements get lost. Agreeing a single set of terms is unglamorous and it removes a whole category of defect that no amount of testing would have caught, because the code did exactly what somebody asked for.

The second guards against building things nobody asked for. The third is a limit on the first two: a team can spend arbitrarily long agreeing vocabulary and value, and at some point the remaining uncertainty is cheaper to resolve by writing code than by discussing it.

The practical consequences are covered under the BDD process, and the notation used to write the examples under Gherkin syntax.