Behavior-Driven Development (BDD): Behave, Will You?

In our previous article, we talked about test-driven development known as TDD and how it can make your app flawless (or nearly so). Today we’ll take it one step further and discuss behavior-driven development (BDD). This methodology combines TDD and acceptance testing practices and helps developers create apps that are centered around business needs. 

“But wait, aren’t all apps centered around business needs? Like, is that the whole point?” Indeed. However, BDD helps you achieve business goals in a more effective manner and make sure that users will 100% receive what they expect. Without further ado, let’s get started.

Explaining behavior-driven development in simple English

First, let’s clarify the following: BDD is an Agile software development methodology and can be called a natural extension of TDD. This is because with BDD, the app is also developed only after behavior-specific tests are designed. 

What it means is that the development team wants the app to behave exactly as intended and as users expect it to behave. So in order to achieve that, the team first outlines and documents desired behaviors, creates acceptance tests, and only then builds the app around it. The final goal here is for the app to pass the tests and display the needed behavior.

The main value of the BDD approach is that the development process involves not only the development team, but stakeholders as well. This expands the feedback pool and helps ensure all objectives will be met.

How to perform behavior-driven development

Say, you want to implement the BDD approach on your project. Where do you start from?

Normally, the BDD lifecycle would look as follows:

• Description of the desired behavior 
• Definition of requirements
• Run (and fail) of behavior-specific tests
• Coding/implementation of features needed for the specific behavior
• Run (and success) of tests

Let’s look at these stages in a bit more detail – trust us, there are many things to be aware of.

Description of the behavior and definition of requirements

The first thing that needs to be done is the discussion of the expected app’s behavior. Involved members of the discussion normally include a business analyst, the dev team, stakeholders, and QA team. Once the expected behavior is defined, the BA lists it in a feature file that is later shared with the developers to base acceptance tests on.

You might want to stop here and ask the following questions: how do you define expected behavior to ensure it 100% hits the target? The most common methods involve creation of user stories and the 5 Whys method. We’ve already talked about user stories before, but let’s do a quick recap. 

A user story is a description of a user journey, aka the stages of interaction between a user and a product.  Users stories are written in a non-technical language, so they can be understood by anyone and normally contain a user, an action, and the value that the user receives from the action. Definition and listing of user stories helps the development team understand how users will interact with the product and what actions/features are to be implemented.

Now, what is the 5 Whys method? You might have come across it since it’s widely used not only in software development but in various domains and even in our lives. The method originated in the 1930s and was invented by Sakichi Toyoda, the founder of Toyota Industries. Its main goal is problem-solving, which is performed by asking “Why?” 5 times and thus, drilling down to the problem’s root. 

Here is an example: “Why is our sales team not meeting its KPI?” Once you get an answer, you again confront it with the “Why” question and repeat three more times till you identify what really was causing the issue. 

The 5 Whys method is useful when thinking about user behavior on an app since it helps get straight to the point without distracting on possible “but what if”.

Design of acceptance tests

The next step in the BDD methodology is writing behavior-specific tests. An important thing to remember here: the tests are written in a DSL (domain-specific language) and by using a fixed syntax. This is needed so everyone can understand the meaning of each test and what it’s supposed to do. We will look more closely at BDD frameworks below, no worries.

Now, for the tests, all of them follow a fixed format: 

• Given: a condition/ a scenario
• When: an action is triggered by user and is happening
• Then: the result of the action.

Let’s look at an example. Say, we have a scenario where a user logs in an app. The format of the BDD test will look like this:

• Given the user is on a page with a login form
• And the user enters the “Test0” username
• And the user enters the “Pass12” password
• When the user clicks “log in”
• Then the user is taken to a home page.

As you can see, a test can be easily understood by anyone, not necessarily with a technical background. Another important note: all tests will fail since there are no features implemented yet. Their implementation happens in the next stage.

Coding and secondary testing

After you created tests, it’s time to write some code, so these tests can pass. There is not much to discuss here except for the use of specific frameworks (that we will talk about very soon) and the fact that developers normally use the Gherkin programming language, which has a syntax similar to English. The main goal here is to write only those features that are needed for the defined behavior – in this way, you won’t be writing any unnecessary or extra code.

Main BDD frameworks and tools

Behavior-driven development requires the use of specific tooling, so tests can be understood not only by the machine but by humans too. As well, these tests have to follow the above-mentioned format – so here are the most common BDD tools:

• Cucumber: an open-source testing framework that allows writing specifications in Gherkin. The framework also supports Ruby, .NET, and Java and platforms such as Ruby on Rails and Spring Framework.
• Gauge: another open-source test automation framework which is also cross-browser. Unlike Cucumber, Gauge works with a variety of languages and integrates with several IDEs.
• JBehave: an open-source framework that is used for Java-based development mostly. As well, JBehave is used for microservices testing and is very customizable.

The biggest benefits of behavior-driven development

There are several benefits that the BDD approach brings to a product – below we will look at the biggest ones.

Usability and adherence to the requirements

Because the BDD methodology is centered around app’s behavior, it’s natural that the app will have a very high usability and will 100% correspond to the requirements and user needs. As well, the app will precisely meet all business objectives and will be very user-centric.

Collaboration and inclusion

In traditional software development, it’s up to the development team to come up with user stories and decide what features to implement to meet the client’s requirements. With BDD, all stakeholders are involved in the development process and anyone on the team can write behavior scenarios since plain language is used for that. Needless to say, such inclusion significantly expands the feedback pool and offers everyone in-depth visibility of the project.

Automation

When there are hundreds of tests, you wouldn’t want to perform them all manually. BDD frameworks allow turning scenarios into automated tests easily because the scenarios outline all needed steps. The only thing a QA engineer has to do is write a method or a function to perform operations for each step.

Code clarity 

Because each scenario focuses on a specific behavior, it is always clear what each feature is supposed to do. And due to plain language used, there will be no ambiguous code or heavy tech jargon. As well, there will be no duplicate or unnecessary code which contributes to the app’s performance significantly. 

Adaptability

Simply-written scenarios can be:

• Updated in accordance with product changes
• Filtered by a tag name, if needed, to decide what should and shouldn’t run;
• Parameterized so they can be reusable and adaptive.

In this way, BDD offers high adaptability and allows scenarios to be reused as much as needed.

Final word

Despite its advantages, behavior-driven development is not for everyone – or to put it more accurately, is not for every project. For example, BDD simply won’t work with the waterfall approach and BDD requires the dev team to have a quite high technical expertise and knowledge. As well, BDD is very demanding in terms of crafting requirements and scenarios – you can’t just let them be, you have to work on them really hard, so everything is crystal clear. And while it might seem like too much work for some teams, in a long run, behavior-driven development rewards you with amazingly user-friendly products that have been thoroughly tested even before the code was written. Now, how cool does it sound?