BDD Meaning: What Is BDD, and How Is BDD Defined and Explained?

The BDD meaning is narrower than most introductions suggest. Behaviour driven development is a practice in which a team agrees on what a piece of software should do by writing that agreement down as concrete examples, in language every person on the team can read, before the code exists. The examples are precise enough to be executed automatically, which is why BDD is so often mistaken for a testing technique. The tests are a by-product. The agreement is the point.

The term was coined by Dan North in the mid-2000s, and set out in his 2006 article Introducing BDD. North’s account is explicit that the origin was a teaching problem rather than a tooling one: developers learning test-driven development kept stumbling over the word “test”, and the vocabulary was getting in the way of the idea.

What is BDD in practice: the BDD meaning a team can use

The BDD meaning most teams settle on has three moving parts, and the question what is BDD is easiest to answer by walking them in order rather than by reaching for a one-line BDD definition.

A conversation happens first, between someone who understands the business need, someone who will build it, and someone who will probe it for holes. This is often called the three amigos, and its output is not a document but a shared understanding.

That understanding is then written as examples. Not a description of the feature in the abstract, but specific cases with specific values. “The account has enough money” is a scenario. “The system should handle withdrawals correctly” is not.

Finally the examples are automated, so that the agreement can be checked against the running system whenever anyone asks. Once those three parts are in place the BDD meaning is fully defined; anything else a team adds is tooling preference. Once automated they double as documentation that cannot quietly go out of date, because it fails when it stops being true.

The BDD definition rests on three principles

North’s original formulation gives three principles, and any usable BDD definition has to carry all three. They are worth reading as constraints rather than aspirations.

Business and technology should refer to the same system in the same way. Two vocabularies describing one system is a defect, not a translation layer. This is the idea later named ubiquitous language in domain-driven design.

Any system should have an identified, verifiable value to the business. If nobody can say what a feature is worth, the honest response is to stop and find out rather than build it.

Up-front analysis, design and planning all have a diminishing return. Enough is enough. The examples are written just before the work, not months ahead in a specification nobody rereads. Explained together, the three principles describe a team that decides late and decides once.

What BDD is not, clearly defined

Asking what is BDD tends to produce a clearer answer in the negative. It is not a test framework, and adopting Cucumber does not make a team practise BDD. A common failure mode is a project with several hundred automated scenarios that were all written after the code, by one developer, and read by nobody. The scenarios run, so the build is green, and none of the value has been captured because the conversation never happened.

It is also not a replacement for unit testing. BDD operates at the level of behaviour a stakeholder would recognise. The internal design of a class is not that level, and trying to express it in Given/When/Then produces scenarios that are unreadable to the only audience that justified writing them.

Nor is it inherently slower. The cost it adds is the conversation. The cost it removes is the rework that follows from building the wrong thing precisely. Explained in those terms, BDD is a scoping practice that happens to leave executable artefacts behind.

How BDD relates to TDD and ATDD, explained

Test driven development is a design discipline for the inside of the code: write a failing test, make it pass, improve the structure. BDD keeps that rhythm and moves the outer loop to a level a non-programmer can read. Acceptance test driven development sits in much the same place, and in practice the distinction between ATDD and BDD is largely one of lineage rather than mechanics. The longer comparison is set out separately.

Set out that way, the BDD meaning is narrower than it first appears: the practice is defined by where the agreement is made, not by which tool executes it. The practical difference is where the first sentence gets written. In TDD it is written in a test file by a developer. In behaviour driven development it is written in a room, by three people, and only then moved into a file.