revolves around the concept of a Scenario, which represents an automatable execution of business functionality. At its core a Scenario comprises of a number of executed steps. These Steps can be of three types:
Scenario: A scenario is a collection of executable steps of different type A Given step represents a precondition to an event A When step represents the occurrence of the event A Then step represents the outcome of the event
Given, When and Then are also called BDD Keywords
A Story or a Feature, in turn, comprises of one or more Scenarios.
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 langauge 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 emphasys 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.