What is behaviour driven development (BDD)?
Behaviour Driven Development (BDD) is the way of writing acceptance criteria by giving examples of how software should behave in different scenarios. They are written in a standard format that promotes clarity, as well as allows easy integration with automated testing.
The standard format is as follows:
Given some preconditions, context, or starting point,
When some actions, events or inputs occur,
Then some specific result is expected.
Scenarios
Let’s say you are building a feature allowing users to log in to your system. The first step is to identify the scenarios that your software will have to respond to, such as:
A user logs in successfully.
Someone has forgotten their password.
Incorrect details are entered.
Incorrect details are entered five times.
There is no internet connection.
Each scenario is an example of the type of situation your software might need to respond to. The list of scenarios represents the scope you intend to build for the feature in question.
The next step is to have a conversation about how the software should behave in these scenarios by considering the preconditions, actions and desired response in each case. This is typically done shortly before the feature is developed, with representatives from the business and technology working together to produce full BDD scenarios:
Scenario: A user logs in successfully
Given I’m logged out and on the home page,
When I go to the login page and enter valid details,
Then I am redirected back to the home page and my name appears in the top right corner.
Using small, self-contained examples of behaviour but nonetheless, getting into a very specific level of detail exposes assumptions and allows them to be clarified, reducing the chance that features will have to be re-worked by developers. For example:
Scenario: A user enters the wrong password
Given I am on the login page,
When I enter a valid email address but an incorrect password,
Then …
Should we tell the user that the email is correct, or just give a general error saying the details do not match our records? BDD exposes this choice and allows it to be made before the development begins.
Automated testing
As the feature is being developed, many teams chose to build automated tests to verify that the software behaves as described in the scenarios. Test automation packages including cucumber, behat, specflow, jbehave, and codeception will take plain-text scenarios written in natural language, and allow test automation specialists to create automated regression tests. As your software grows in scope and complexity, these automated tests form part of your quality assurance and give confidence that features built in the past have not been broken by more recent changes.