A definition of BDD

Behaviour-Driven Development (BDD) is about implementing an application by describing it from the point of view of its stakeholders

Stories, scenarios and steps

BDD revolves around the concept of a Story, which represents an automatically executable increment of business functionality. At its core a Story comprises of one or more Scenarios, each of which represents a concrete example of the behaviour of the system. Each Scenario comprises of a number of executable steps. These Steps can be of three types:

A story is a collection of scenarios

In order to communicate effectively to the business some functionality
As a development team
I want to use Behaviour-Driven Development
Scenario:  A scenario is a collection of executable steps of different type

Given step represents a precondition to an event
When step represents the occurrence of the event
Then step represents the outcome of the event

Scenario:  Another scenario exploring different combination of events

Given a precondition
When a negative event occurs
Then a the outcome should be captured    

Given, When and Then are also called BDD Keywords

A scenario can contain any number of steps, and steps of the same type can follow each other:

Given a wizard named Harry
Given a wizard named Hermione
When the wizards meet
Then a spark should occur

This scenario signals that there are two preconditions to the event of the wizards meeting. As such, it may be expressed in an equivalent way:

Given a wizard named Harry
And a wizard named Hermione
When the wizards meet
Then a spark should occur

We can then introduce another keyword:

A step starting with And assumes the same meaning of the previous step

Communication is the key

aims to provide an automatable description of the behaviour of the system, from the point of view of the stakeholders. As such, it is essential that the language used in the description reflects the language used by the business users. The language and its grammar represents the shared understanding of the behaviour between the business users and the development team. And as any language it evolves with the evolution of this shared understanding. BDD provides the grammar, but the language is agreed between the business and the team.

The emphasis should be placed on concepts relevant to the business, shielding away issues of technical implementation. A good rule of thumb is that if details of the technical implementation can be changed without affecting the overall behaviour, as visible by the business user, then it should not appear in the scenario.


Learn about the full Grammar JBehave supports. Or refer to More on BDD for more BDD-related information.