Article

Behavior-driven development

May 5, 2022

Behavior Driven Development (BDD) is a development methodology that emphasizes meeting the business needs of the software.

Behavior Driven Development (BDD) is a development methodology that emphasizes meeting the business needs of the software.

Behavior Driven Development (BDD) is a development methodology that emphasizes meeting the business needs of the software. It evolved from test-driven development or TDD. BDD uses a domain-specific language and a fixed syntax for developing tests.

What is behavior-driven development?

Behavior-Driven Development, or BDD, grew out of Test Driven Development (TDD). The aim of TDD is to create clean, simple code that satisfies the requirements with no or minimal code bloat. In TDD, the aim is to create code that passes your tests, rather than trying to meet your requirements directly.

BDD takes this a step further, using a domain-specific language and a fixed syntax for tests. This provides a framework in which to specify your features in terms of unit and acceptance tests. In turn, you have to be precise with your language, ensuring you create unambiguous tests. This approach lets you create tests that are closely aligned with the needs of the business. Cucumber was one of the first frameworks for BDD. It was originally released 10 years ago as a tool for Ruby developers. Their domain-specific language for BDD is called Gherkin.

How do I implement BDD?

True BDD is a very formulaic approach to testing and software development. You plan your tests using Cucumber and write them in Gherkin. Gherkin is a language that allows product teams to define requirements for new features. In Gherkin, every feature is defined in a .feature file and follows a very precise syntax. You must use a Gherkin keyword at the start of each line, and each line defines one aspect. The aim is to create unambiguous definitions for each feature which can then be tested precisely.

You can then define your tests that check the feature is correctly implemented. The most important thing is that every test follows a fixed format: Given some condition, when something happens, then you see a result. Gherkin is intended to be human-readable, but, as with formats such as XML, it isn’t always easy to read!

Having defined your features, you use Cucumber to create methods that will implement the tests for each feature. Cucumber was designed for Ruby, but you can also use it to generate Java, JavaScript, or Python methods. Hooks allow you to define pre- and post-conditions relating the test (e.g. the state of a database).

Why is behavior-driven development so useful?

BDD focuses on the needs of the end-user, focusing on how the software actually behaves. Importantly, you define your tests at the same time as you plan your features. Therefore, you know that if your software passes the tests, it implemented the correct features. This is a very different approach to usual.

In a 2006 blog, Dan North explained the origins of BDD.

“Behaviour-driven development started life as an NLP exercise to stem the abuse of the word “test” in “test-driven development”.”

Nowadays, everyone assumes NLP means natural language processing. However, in 2006, the acronym stood for neuro-linguistic programming. So, what Dan North meant was behavior-driven development attempts to shift the emphasis from passing tests to testing correct behavior.

A simple example of a BDD feature

The following is a really simple example of how to write a BDD feature for a login button.

Feature: Login button
A user should be able to login by entering their credentials and clicking on a button.
Provided the user enters a valid username and password, the button should take them to
their homepage.

Scenario
: User enters valid credentials
Given the user is on a page with the login form
And the user has entered the username “test1”
And the user has entered the password “Pass123”
When he clicks login
Then the user is taken to his homepage

Scenario: User forgets their password
Given the user is on a page with the login fields
And the user has entered the username “test1”
When he clicks the “Forgot password” link
Then the user is taken to the reset password page

Scenario: User enters invalid credentials
Given the user is on a page with the login fields
And the user has entered the username “test1”
And the user has entered the password “Pass321”
When he clicks the login button
Then the login form is displayed again with the username still populated and an error message

As you can see, there are several keywords here: Feature, Scenario, Given, When, Then, And. The tests are clearly defined and are easy to understand.

How can I avoid common mistakes?

Probably the most common mistake you can make is to miss out an important test scenario. BDD is only as good as the scenarios you define. The key thing is you have to encourage your development team and product team to work together. The product owners are the people that can ensure you are defining every scenario.

Another major mistake is believing BDD is the only testing you need. BDD is great for testing features, but it can’t test usability, UI defects, performance, etc. Moreover, any user interface tests still need to be converted into test scripts. In other words, BDD is really more about how to write the software, rather than how to test it.

What are the common challenges I might meet?

The main challenge with BDD is the formulaic nature of Gherkin. This makes it quite challenging for your product team who are more used to writing user stories. They will have to shift to a different way of thinking. Rather than focus on the user outcomes, they have to think of the specific features that should be developed.

Also, it can be pretty challenging to combine BDD with Agile development. BDD is ideal in a waterfall model project where your requirements are fixed. But in Agile, you constantly adapt your product to the changing needs of the end-user. This means you will need to rewrite features and tests as you go. This could result in double the work you would otherwise have done.

Conclusion

Behavior-driven development helps you focus on creating better software. It is designed to shift the emphasis from passing tests to delivering features. However, it isn’t a panacea and won’t work for every project.