« Table of Contents »
Previous « Developers: No Other Automated Tests!
The Behaviour Specification Handbook
Behaviour Specifications
Overview Of The Gherkin Language
Behaviour Specifications can be written in different ways, and the most renowned is with the Gherkin language.
The Gherkin language is the most widely used and recognised business-readable, domain-specific language (DSL) for specifying behaviours.
Each behaviour is defined as an individual “Scenario”.
A “Scenario” has a description that summarises the behaviour being specified.
The behaviour is then further defined as a series of steps to be executed in the order in which they are written — just like the steps of a test case.
The syntax of the Gherkin language specifies that each step begins with one of the following keywords: “Given”, “When”, “Then”, “And” or “But”.
The “Given” steps must be specified before the “When” steps, which themselves must be specified before the “Then” steps.
The “Given” steps define the prerequisite state that is required for the behaviour to manifest.
The “When” steps define how to initiate the behaviour being specified.
The “Then” steps define how to verify that the behaviour performed as expected.
Steps that begin with “And” or “But” merely allow for more details to be specified and extend the meaning of the proceeding “Given”, “When” or “Then” step.
The Behaviour Specifications are logically grouped as a “Feature”.
A “Feature” also has a short description that summarises the scope of the logical grouping of behaviours.
While not necessarily specific to the Gherkin language (it depends on the implementation of the tooling that parses the Gherkin language), each “Feature” typically is stored within a file with a suffix of “.feature”.
There are various tools in each different technology platform for parsing and executing the Gherkin-based “Feature” files.
For instance, in Ruby there is Turnip, Spinach and Cucumber, in .NET there is SpecFlow, JBehave for Java, Behat for PHP, Gauge, and many others.