Behaviour driven development

David Buckhurst & Rebecca Salsbury on behaviour driven development

Behaviour driven development (BDD) is a workflow for software development, inspired by the habits of the most efficient test driven develpment (TDD) teams. It aims to bring together best practices via a clear and simple language. Technical architect David Buckhurst and head of core engineering at BBC News & Knowledge Rebecca Salsbury explain how BDD focuses on application behaviour from the user point of view.

Rebecca explains that BDD helps teams to translate the business requirements into a language the software developers can implement. The methodology refers to this as a ubiquitous language.

BDD workflow:

1. Take a requirement from a specification to create a feature
The process begins with requirements documentation, also called specifications, which detail how an application should work. Software developers work with the product manager, who owns the specification, to break down the requirements into features. Taking the example of a calculator app, that feature might be something like 'addition'.

2. Create a number of scenarios that illustrate how the system should behave
Having decided on a feature, the next step is to come up with examples of the behaviour the system would exhibit for that feature (known as scenarios). With an 'addition' feature, the scenario could be 'adding two positive numbers'.

It is important to describe the scenario in plain English to give the test focus, so that it tests for exactly what the sentence says. This also means other developers will immediately understand what the scenario is about without having to read lines of code – and if there is failure in future, it will be instantly clear which aspect of the application’s behaviour is broken. 

"BDD allows us to visualise features and scenarios in a way that’s useful for everyone" – David Buckhurst

3. Develop the scenarios with steps
The next step is to add details to flesh out the scenario, using Gherkin’s Given/When/Then syntax:

So for, the scenario 'adding two positive numbers', the steps would be -

Given I enter '2 + 3'
When I press '='
Then the display should say '5'

4. Automate the steps and write the code
A 'three amigos' meeting is held between the product manager, tester and developer to develop the test. Once the scenarios have been fleshed out in Gherkin, each step can be rewritten as code that can actually be executed. Cucumber manages the mapping between the human readable Gherkin steps, and the machine-executable test code.

5. Executing Cucumber
Once a full scenario is automated, Cucumber can run it against the work-in-progress system. If any step fails to execute as expected, Cucumber will report that the scenario has failed and there is a problem with that feature.

Rebecca explains that many teams find BDD challenging at the outset, as they feel they have to rigidly stick the framework and the exact language. Rebecca encourages her teams to adapt the framework to get the most out of it for their needs.