What is Behavior-Driven Development (BDD) Framework?

In this complete guide to Behavior-Driven Development, we’ll answer all your questions about this framework so you can understand all the benefits of BDD to start using it.

Throughout this article, you’ll find:

• Definition of Behavior-Driven Development
• Difference between TDD and BDD
• How BDD can solve communication issues
• Three Phases of BDD
• BDD Examples
• Benefits of BDD
• How BDD has helped Cheesecake Labs

The Definition of Behavior-Driven Development

BDD stands for Behavior-Driven Development.

Originally created in 2003 by Dan North, it is known to be an Agile approach to software development and it is emergent in this industry.

It aims to do exactly what the title suggests: lead your development driven by behavior.

BDD can be defined as a technique that encourages collaboration among developers, quality assurance, and business analysts in a software project.

Dan North himself developed the first automated BDD testing framework in Java: JBehave. And after that, came RSpec and Cucumber.

Test Driven Development vs Behavior-Driven Development

Behavior-Driven Development actually began as an evolution or complement for TDD (Test Driven Development).

Basically, TDD proposes the elaboration of simple tests before the code definition. 

But what to test and what to evaluate?

Here comes the BDD. The main goal of BDD is to bring non-technical people to approach how to understand and define the tests.

In fact, tests are not the main purpose of BDD. Practicing BDD means we’ll specify and execute tests, but the main purpose is to achieve business goals and customer outcomes according to the application level.

Using BDD to solve communication issues

One of the biggest problems that a development team faces nowadays is communication.

It is uncommon that a business analyst would ask a task for devs using technical language, because the analyst will be mainly worried about what the customer expects, and not about what technology the developers need to use. 

BDD helps simplify communication using scenarios described by the customer or analyst, and those become easily understood by the whole team.

The core idea of BDD is that no one person or field has the full answer to anything.

“The Three Amigos“

Sometimes, there is a “Specification Workshop”, where the Product Owner, Quality Assurance and Developers meet and discuss the requirement in the form of specification.

They are also called “The Three Amigos”, and are made up of at least one person from the following 3 areas: Business, Development, and Testing.

Business professionals bring customer requirements and business needs. 

Developers know all the technical requirements and software needs, so they know how easily or hard the stories can be implemented. Testers identify edge cases, obstacles, and gaps in the stories.

The Structure: BDD phases

Usually, BDD is divided into three phases, which are: 

1. Discovery: A story is explored in a conversation. First, we need to ensure the story will contribute to business outcomes, and so the development team needs to have a clear understanding of what is required.
   
   It’s when we discover what business outcome is served, what we need to do, what are the blockings, what can happen or not happen, etc.
   
2. Formulation: The stories are formulated in a structured language, like the given-when-then pattern (see the structure below).
   
   We need to be careful to certify we know what to do by the discovery phase.
   
3. Automation: When necessary, the structured language can be used as executable specifications for automated tests.

Given-When-Then language structure

The main BDD structure is defined by at least 3 words: Given, When, and Then.

• Given: An initial state or condition. Usually describes the context before your feature is triggered.
• When: An action is taken. The behavior being described.
• Then: The output of this behavior. The expected outcome has given the initial state and after the triggered behavior.

Understanding BDD through an example

Planning and developing through examples is one of the key concepts of BDD. Giving real case scenarios of what you should expect from the product can make everything easier for everyone.

So let’s see an example:

Feature: Money transfer

• Scenario A: Transfer an amount of money lower than my balance
  • Given: I have $500 in my account;
    And John has $700 in his account
  • When: I transfer $200 from my account to John’s account;
  • Then: I should have $300 in my account;
    And John should have $900 in his account.

• Scenario B: Transfer an amount of money bigger than my balance
  • Given: I have $100 in my account;
    And John has $700 in his account
  • When: I transfer $200 from my account to John’s account
  • Then: I should have $100 in my account;
    And John should have $700 in his account.

Here we are describing money transfers. We have detailed the scenarios and if you have noticed we have predicted a case where the behavior was not concretized.

We have also taken care of making everyone in the project understand what exactly the term account means. Considering that you will find more complex terms eventually, this needs practicing.

Check more BDD Examples: How to Develop Tests for a Pokédex Using BDD

What are the benefits of BDD?

Behavior-Driven Development is very useful for agile projects.

Mainly because we already know that agile projects are going to need several updates, and BDD helps the project stay in line.

• Using BDD helps communication among the team, so developers, testers, and other professionals can easily work together;
• Sometimes the documentations are expensive, but with BDD we can make it dynamically without extra effort;
• Business goals and customer requirements are put in front and center;
• It is also helpful for project managers, product owners, and other management roles because we have better visibility of the whole project;
• Working on a project guided by tests is extremely helpful. We can develop a quality code, reducing the number of bugs and having less costly maintenance in the future;
• It is easy to learn because the given-when-then canvas is closer to everyday language;
• The acceptance criteria is defined before development begins;
• If necessary, we can easily develop automated tests with BDD.

How the BDD framework helped us in Cheesecake Labs

Behavior-Driven Development documentation has helped the whole team stay aligned with the business updates, which brought faster development with a minor amount of bugs.

It also helped to bring the development team to the customer/business specification closer. 

This way, we could work directly toward the defined business acceptance criteria by the BDD structure.

Mapping BBD scenarios before developing helped us develop in a test-oriented way, which is similar to TDD.

This way, we could test the software from the beginning of the project, while also testing the case uses, finding misunderstandings, edge cases, and polishing acceptance criteria.