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.
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 of, or complement to, 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 BDD. The main goal of BDD is to bring non-technical people closer to understanding and defining 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.
How does BDD solve communication issues?
BDD solves communication issues by describing requirements as scenarios in everyday language rather than technical terms, so business, development, and testing all read the same description of what the software should do. One of the biggest problems that a development team faces nowadays is communication.
It is uncommon that a business analyst would write 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 easy 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:
- 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 blockers, what can happen or not happen, etc. - 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 confirm we know what to do from the discovery phase. - 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, 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.
- Given: I have $500 in my 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.
- Given: I have $100 in my 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 documentation is expensive, but with BDD we can make it dynamically without extra effort;
- Business goals and customer requirements are put 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 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 are defined before development begins;
- If necessary, we can easily develop automated tests with BDD.
How the BDD framework helped us at Cheesecake Labs
Behavior-Driven Development documentation has helped the whole team stay aligned with the business updates, which brought faster development with fewer bugs.
It also helped to bring the development team closer to the customer/business specification.
This way, we could work directly toward the business acceptance criteria defined by the BDD structure.
Mapping BDD 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 use cases, finding misunderstandings, edge cases, and polishing acceptance criteria.
