Behavior-driven development

Behavior Driven Development (BDD) is a methodology that emphasizes meeting the business needs of the software. It evolved from test-driven development or TDD, and 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). TDD aims to create clean, simple code that satisfies the requirements with no or minimal code bloat. In TDD, the aim is to generate code that passes your tests rather than to try to meet your needs directly.

BDD takes this further, using a domain-specific language and a fixed syntax for tests. This provides a framework to specify your features regarding unit and acceptance tests. You must 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, and it was initially 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 precise syntax. It would be best if you used 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 to 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 to the test (e.g., database state).

Why is behavior-driven development so helpful? BDD Benefits

BDD focuses on the end user’s needs and how the software behaves. Importantly, you define your tests simultaneously as you plan your features. Therefore, if your software passes the tests, it implements the correct features, which is a very different approach from 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.”

If a team is already using Test-Driven Development (TDD) or Acceptance Test-Driven Development (ATDD), here are the benefits they can leverage from Behavior-Driven Development:

• BDD provides more precise guidance on organizing conversations between developers, testers, and domain experts, leading to more effective communication and collaboration.
• The notations used in BDD, such as the given-when-then canvas, are designed to resemble everyday language, making it easier for technical and non-technical team members to understand and use.
• BDD tools often offer automatic generation of technical and end-user documentation from BDD specifications, which can save time and improve documentation quality.
  

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 straightforward 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 easy to understand.

How can I avoid common mistakes?

The most common mistake you can make is to miss out on a critical test scenario. BDD is only as good as the scenarios you define. The key is to encourage your development and product teams to work together. The product owners are the people that can ensure you are describing every scenario.

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

What are the common challenges I might meet? BBB Pitfalls

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 must consider the specific features that should be developed.

Also, it is 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, which could 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.