Behaviour Driven Development (BDD): Practices, Tools and Examples

What behaviour driven development asks of a team

The practice makes one demand, and everything else follows from it: the people who want the software and the people who build it have to agree on specific examples before the work starts. Not a description of the feature, and not a definition of done. Specific cases, with specific values, including the ones where the answer is no.

That demand is organisational rather than technical, which is why behaviour driven development is harder to adopt than any tool suggests. Writing the examples takes a conversation between someone who understands the need, someone who will build it, and someone whose instinct is to look for the case nobody considered. The three together find the disagreement that none of them would have found alone.

What the team gets in return is a decision made once. The examples become the acceptance criteria, the specification and, once automated, the regression suite. They also stop being true the moment the behaviour changes, which is the property that ordinary documentation never has.

The practices BDD adds to an ordinary week

In day-to-day terms the practices are unglamorous. A short session before work begins, in which the examples get written on a board and argued over. A habit of stating outcomes in terms the person who asked for the feature would recognise. A rule that a scenario describing internal mechanics belongs in a unit test instead.

Teams that get value from BDD tend to apply these practices selectively. The features where the rules are contested, or where a misunderstanding would be expensive, earn the conversation. Well-understood mechanical work does not, and forcing it through the same process is the most common way the practice gets abandoned.

The vocabulary matters more than newcomers expect, because the examples are only useful if a non-programmer can spot that one is wrong. Getting the words right is a practice in its own right, and the reason the notation looks so plain.

Worked examples resolve into checkable clauses

The value of writing examples this way shows up when one of them cannot be resolved. A clause that no machine can check is usually a clause no human agreed on either. "Then the customer is happy" fails both tests, and rewriting it forces the question that the original wording let everyone avoid.

Two further examples make the point. A scenario that begins with four Given clauses is describing a context so specific that the rule underneath it is probably narrower than the team thinks. A scenario with three When clauses is describing more than one behaviour and should be split.