The BDD Process, Step by Step: From Conversation to Executable Example

The BDD process is short enough to state in four steps, and most of the difficulty is in the first one, which produces nothing you can put in a repository.

Step one: the conversation

Three perspectives meet: someone who understands why the work is wanted, someone who will build it, and someone whose instinct is to find the case nobody considered. The arrangement is often called the three amigos.

The output is not a document. It is the discovery that the three of them had three different pictures of the same feature, which is the point of the meeting and the reason it cannot be replaced by a written specification circulated for comment.

Step two: write the examples

The understanding is written down as concrete cases with real values. Not a description of the rule, but instances of it, including the ones where the answer is no.

Real values are what force agreement. Large withdrawals need approval can be nodded through by two people who mean different numbers by large. Given a withdrawal of 5,000 cannot.

Step three: automate them

The examples are wired to the system so they can be checked whenever anyone asks. This is where the tooling comes in, and it is the least interesting step, because which framework does it is a consequence of the language the team already writes.

Once automated the examples become documentation that fails when it stops being true, which is a property ordinary documentation does not have.

Step four: implement until they pass

Development proceeds against the examples, typically with test driven development driving the design underneath. The scenarios are the outer loop; the unit tests are the inner one.

Where the process breaks

Almost always at step one, because it is the only step with no artefact and therefore the only one whose absence leaves no trace in the codebase. A team that writes Gherkin after the code, alone, has performed steps two through four faithfully and captured none of the value.

The second common break is at step two, where examples get written as descriptions rather than instances. Then the order is processed appropriately passes review, automates cleanly, and records no agreement about anything.

A third break is quieter. The conversation happens, the examples get written, and then the implementation drifts because a decision made at the keyboard was easier than reopening the discussion. The examples still pass, because they were adjusted to match. Nothing in the tooling can catch this; the only defence is treating a change to an agreed example as a change to an agreement, which means telling the people who made it.

How long the loop takes

For one feature, the whole of steps one and two is usually under an hour, and often twenty minutes. That figure surprises teams who expect the practice to be expensive, and it is worth stating plainly because the perceived cost is what stops adoption more often than the real one.

Where sessions run long, the cause is almost always one of two things. The feature is too large and should be split, or a decision is needed that nobody in the room is authorised to make. Both are useful findings, and both are cheaper to discover in a meeting than in a sprint review.

What the process looks like once it is habitual

Less like a process. The conversation stops being a scheduled ceremony and becomes the fifteen minutes before someone starts work; the examples get written on whatever is nearest and moved into a file afterwards.

The visible artefacts do not change, which is why teams sometimes conclude the practice has lapsed when it has actually been absorbed. The test is whether disagreements about behaviour still surface before implementation rather than at review.

Why the order matters more than the artefacts

Every step of this process can be performed out of order and still produce the same files. That is the reason the practice is so easy to adopt in appearance and so hard to adopt in substance.

Examples written before implementation are an agreement. The same examples written after implementation are a description of what was built. They are textually indistinguishable, they automate identically, and only one of them can tell a team it was about to build the wrong thing.

This is also why measuring adoption by counting scenarios never works. The count is identical either way. The only reliable signal is whether behavioural disagreements are surfacing before code is written or during review.

Where the process needs adapting

Distributed teams lose the whiteboard, which matters more than it sounds: the value of the conversation comes partly from three people editing the same artefact at once. A shared document being typed into live is a reasonable substitute; a call where one person reads out their draft is not.

Regulated work has the opposite problem. There is usually already a formal requirements document, and the temptation is to run this process alongside it, producing two sources of truth. The better arrangement is to make the examples the detail layer that the formal document references, so there is one place where behaviour is stated.