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
Narrative:
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
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.