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.

Next » Thoughts On Gauge

BDD Behaviour-Driven Development Behaviour Specification Handbook Behaviour Specifications Scenarios Testing Gherkin Gauge Specflow Cucumber

Thoughts On Gauge

« Table of Contents »
Previous « Overview Of The Gherkin Language

The Behaviour Specification Handbook

Behaviour Specifications

Thoughts On Gauge

The relatively new kid on the street is Gauge. Gauge is an alternative and similar way of specifying behaviours, but it does not follow the Gherkin syntax. In Gauge, behaviours are defined in “Specification” files that follow the Markdown syntax. Each Behaviour Specification is described with a heading and description, and then is defined further as a series of executable steps.

The main difference between the syntaxes used in Gauge and Gherkin is that there is no specific syntax in Gauge that must be followed to define each step. In Gauge, each step can be written completely in free-text. There is no “Given”, “When”, “Then” restrictive syntax like in Gherkin, and this flexibility can be a powerful drawcard for some people.

However when used in real life within the context of a business, this flexibility and power can be counter-productive. In a business, teams need to act responsibly and in a cost effective manner — which means teams should have agreed standards that are consistently followed. Consistency in language, communication patterns and style is important in a business in order to minimise the overall costs of development, maintenance and staff training. If a business decided to use Gauge as their Behaviour Specification and execution tool of choice, the first thing the business should do, in order to keep costs to a minimum, is to create a standard style guide to promote consistency. An effective standard more than likely will significantly restrict the syntax of the steps — so the drawcard of free-text becomes a moot point. In the end, you may as well have just used Gherkin. The Gherkin syntax “ain’t broke” and is quite effective — although as you will see later, I recommend an even more restricted style!

Sure, there are many cross-language features in the Gauge tooling that may pique your interest, and if you need that functionality then go for it — but please don’t base your decision on the flexibility of free-text steps!

I have found that the Gherkin syntax is an excellent foundational structure, and I will continue to recommend it. Since the Gauge syntax is unrestricted, the recommendations presented here can be applied easily within Gauge specifications as well.

Next » Feature Files

BDD Behaviour-Driven Development Behaviour Specification Handbook Behaviour Specifications Scenarios Testing Gherkin Gauge Specflow