Behaviour-Driven Development with Gherkin

Written by Jane Orme, Software Developer

Efficient software development occurs when the required functionality is understood unambiguously prior to development work commencing. The key goal is to describe the behaviour concisely in a human-readable way that non-technical stakeholders can understand. These conversations start communication about the requirements very early, improving quality and understanding for everyone involved.

Most people have heard of Test-Driven Development (TDD), and Behaviour-Driven Development (BDD) is a variation on that. Test-Driven Development helps to build a suite of unit tests from a technical perspective, beginning with the tests and then implementing the code to make the tests pass. This helps to detect errors and integration problems early.

BDD has an emphasis on the behaviour and user journey through the system to describe requirements; how the software is supposed to behave. Using runnable tests to describe requirements and features is also known as “executable specifications”.

At Bluefruit, when a new feature is planned the software requirements for it are written as BDD acceptance tests in a language called Gherkin. These are written in collaboration with the stakeholders.

What is Gherkin?

Gherkin is written using a ubiquitous language which focuses on describing a feature to be implemented using a “Given…, When.., Then..” format; for example:

Scenario: <title>

Given <some starting state>

When <some action or behaviour occurs>

Then <the desired outcome occurs>

Features described in this way are easily read and understood by people from a variety of backgrounds:

Scenario: A high water temperature triggers an alarm and stops the pump
Given the water temperature is below the maximum temperature,
When the water temperature goes above the maximum temperature,
Then the alarm LED is turned on
And the pump is stopped.

Keeping the tests in plain English makes them easier to maintain and adapt when requirements change.

Why do we use BDD?

Writing requirements in this manner help to gain early collaboration and understanding between stakeholders, and to raise any questions at an early stage before development begins. This saves time and cost in the long run.

Once implemented, tests can be run regularly and automated on a build server to ensure that the software keeps doing what it is supposed to do even when changes are made in other areas. Any regressions are discovered and fixed early.

It helps those who read the tests to visualise what the feature might look like, to ensure that the planned feature will meet the user needs.

Some benefits of writing BDD tests include:

• Stakeholders can understand the requirements
• Stakeholders can see passing tests as an indicator of the quality of the software
• Developers know what they need to implement and automate
• Testers can use them as test cases

Check out the links below for more information on how to achieve quality-focused embedded software development.