Behaviour driven development
The BBC's David Buckhurst and Rebecca Salsbury explain 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. Television platforms engineering manager David Buckhurst and director of platform for design and engineering 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.
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.
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.