Behavior Driven Development Benefits

Is BDD worth the overhead?

By Elena Marin, QC Engineer, Cognizant Softvision

Many years ago, during a training class, I heard about Behavior Driven Development (BDD) for the first time. I remember like it was yesterday, after listening to the trainer’s explanation, my first reaction was: “Is this really used in practice?” In my mind, I thought that BDD was another process created to bring more overhead for the team. I said to myself that it will not be worth the effort (versus its benefits) and I will not use it in any of my projects.

Years later, after I used it in a real project, I realized that BDD comes with a lot of benefits.

BDD is not a new concept for 2021. Most organizations have adopted BDD as the most effective way to translate business requirements into good software. But, before going to the benefits, let’s break it down and first see what BDD is.

So, what is BDD really?

BDD is a software development process. It starts with creation of simple scenarios about how an application should behave from the end user’s perspective. Behavior Driven Development, or BDD, is a branch of Test Driven Development (TDD). As a difference between BDD and TDD, we should bear in mind that in BDD we ensure we build the right things while in TDD we build the things right.

The general principles of BDD include reframing tests as descriptions of system behavior. “When I do one thing, I should see this result.” Over time, the use of BDD shifted toward Gherkin, an English-like language parser.

Gherkin is the engine behind the scenes. Using Gherkin it’s possible to use a human readable format to create tests. It’s also possible for non-technical staff to create descriptions of system behavior. Any programmer or automation tester can transform these descriptions into automated tests and unit tests.

The goal of implementing BDD testing is to improve collaboration between key stakeholders, such as developers, testers, product managers/owners, and business analysts. You achieve this by writing test scenarios in a decipherable language — Gherkin.

To deepen our understanding of BDD, let’s discuss a little bit about the three main ‘key pieces’ of BDD: the artifacts, the domain language, and the process.

Artifacts

When people talk about BDD, they tend to focus on the artifacts. The artifacts are an innovative way of expressing requirements and tests at the same time, using Gherkin syntax.

When people say “BDD” today, they usually mean Gherkin and the use of given/when/then/and/but keywords to describe acceptance criteria.

Gherkin serves two purposes:

(1) serving as project’s documentation and

(2) automated tests (unit and/or functional/acceptance tests).

Let’s see what the Gherkin syntax looks like

Gherkin is a line-oriented language like Yaml or Python. Each line is called “step” and starts with a keyword. Tabs or spaces are used for the indentation and any comment is preceded by a hashtag (#).

Feature: Title of the Scenario

Given [Preconditions or Initial Context]
When [Event or Trigger]
Then [Expected output]

Here are some examples of the Gherkin language for a simple Login behavior:

Feature: Login
As a user
I want to be able to login to the website using valid credentials
So that I will be able to access the application
@ui @regression @smoke
Scenario: Valid login for predefined user
Given I am on the home page
And I open the login screen
And I enter valid login user and password
When I click on Login button
Then I should be logged in
@ui @regression @smoke
Scenario Outline: Valid login for more users
Given I am on the home page
And I open the login screen
And I enter login details '<user>' and '<password>'
When I click on Login button
Then I should be logged in with correct user
Examples:
| user  | password      |
| elena | ElenaPassword |
| ema   | EmaPassword   |

A Gherkin document has an extension (.feature) for writing the tests.

As you can see in the examples above, the behavior description begins with a story called “Feature”. The features are defined using terms from domain language.

Each “Feature” contains one or more “Scenarios”. The Scenarios described above look like plain English, but is it actually a grammar that can be transformed to call software code.

Once the team agrees on the text, a programmer or an automation tester can use some tools to transform the near-English text into stub functions, like in the following example of real C# code:

[Given(@"I am on the home page")]
public void GivenIAmOnTheHomePage()
{
ScenarioContext.Current.Pending();
//Write code here that turns the phrase into concrete actions
}
[Given(@"I open the login screen")]
public void GivenIOpenTheLoginScreen()
{
ScenarioContext.Current.Pending();
//Write code here that turns the phrase into concrete actions
}
[Given(@"I enter valid login user and password")]
public void GivenIEnterValidLoginUserAndPassword()
{
ScenarioContext.Current.Pending();
//Write code here that turns the phrase into concrete actions
}
[When(@"I click on Login button")]
public void WhenIClickOnLoginButton()
{
ScenarioContext.Current.Pending();
//Write code here that turns the phrase into concrete actions
}
[Then(@"I should be logged in")]
public void ThenIShouldBeLoggedIn()
{
ScenarioContext.Current.Pending();
//Write code here that turns the phrase into concrete actions
}
[Given(@"I enter login details '(.*)' and '(.*)'")]
public void GivenIEnterLoginDetailsAnd(string user, string password)
{
ScenarioContext.Current.Pending();
//Write code here that turns the phrase into concrete actions
}
[Then(@"I should be logged in with correct user")]
public void ThenIShouldBeLoggedInWithCorrectUser()
{
ScenarioContext.Current.Pending();
//Write code here that turns the phrase into concrete actions
}

Then, the programmers or automation testers fill in the step definitions. The scenarios use these functions/methods. Once a full reasonable set of steps exist, any member of the team, technical or non-technical, can create new scenarios. Creating a new scenario could be 80–100% reuse and 0–20% new code. Both tests, from the example above, will share common steps.

The artifacts are powerful as principle, but they don’t drive development without real process change.

Domain language

The domain language is the language of the business — customers, books, orders, catalogs, invoices, etc. We can think of orders, for example, as an object, with data like: order number, customer, due date, created date, items, and so on. Orders can also have actions, such as receive payment.

Combining domain language with the artifacts makes a powerful combination. The code will be more clear, shorter, and easier to reuse.

Process

The story template and Gherkin are the artifacts, the permanent record.

The process is a collaboration between development, test, and product owner, sometimes called the three amigos. The BDD process moves through three phases: discovery, formulation and automation. The acceptance criteria are transformed into acceptance tests that are later automated.

The goal here is to:

• Improve first-time quality by building the right thing up-front
• Reduce misunderstandings between technical staff
• Express requirements in unambiguous terms.

Simply stated, instead of one person working alone to create a given/when/then/and/but, the team comes together to discuss what the software will do. These conversations create a shared understanding. All roles in development can contribute to the work. The programmer needs to understand what to build. The testers can ask powerful questions to make sure the behavior described matches the intent. The product owner, analyst, or business person can use the process as a second-check, to prevent building the wrong thing.

The next step is to start creating the automations tests based on the behavior agreed upon. To support regression and continuous delivery, tests should be automated wherever possible.

In development, the practice is to define the feature BEFORE writing any code. This ensures you’re building the right thing — nothing more and nothing less.

The artifacts, the domain language, and the process put together creates a combination that is much more than the sum of its parts. But, without all three of these pieces in place, attempts to “do” BDD will tend to fail.

BDD Frameworks

There are a lot of frameworks on the market like: RSPEC, EasyB, JBehave, but the most popular is, by far, Cucumber. There are Cucumber implementations in about every language you would care about like: Java, Python, C++, .NET (C#, F#, VB.NET), Ruby, PHP.

Here you can find a list with all Cucumber implementations:

https://cucumber.io/docs/installation/

They recommend choosing an implementation for the same platform or program language as the production code. Please note that not all these implementations are officially hosted under Cucumber. Some of them are semi-official, unofficial and even unmaintained. You will see on their page the differences between them. This will help you to make an informed decision when you choose one of these for your project.

Currently, for Automation testing, the most used implementations are:

• Cucumber-JVM for Java
• Behave for Python
• SpecFlow for C#

There are some slight differences between these implementations, in the ease of using them in the IDEs, but the idea behind is the same. All of them are using the Gherkin syntax.

Here you can have more details about the Gherkin syntax:

https://cucumber.io/docs/gherkin/reference/

To improve readability and flow, the used keywords were translated in 70+ languages including some Emoji(em) or even Esperanto(eo).

Well, I’ve never seen Emoji or Esperanto used until now, but (who knows?) maybe they are :).

BDD benefits

So, what can BDD do for you? Why adopt a new process with a new framework? Is it worth the effort? I mean, why change the way you do things in the project?

From my experience, I can say yes, it is worth the effort. Why? Because the main benefits of BDD are collaboration and automation, But besides these, there are also some other awesome benefits using the BDD like:

• Strong collaboration between all the stakeholders involved in the project implementation. It enables everyone involved in the project to engage with the product development cycle. All involved parties have a strong understanding of the project. They can also have a role in communication, which leads to constructive conversations. More on this, anyone can write behavior scenarios because they are written in plain languages. Scenarios are:

— Requirements for product owners

— Acceptance criteria for developers

— Test cases for testers

— Scripts for automators

— Description for other stakeholders

• More clarity — the scenarios are focused on one specific thing. This will help a lot to clear the ambiguity of the new implementations. Clarity ensures the customer gets what they want. There is also clarity in the code. No technical jargons are used anymore and there is no game of telephone. This also reduces misconceptions and misunderstanding. It’s easier for new members to join the working process and understand easier the functionalities.
• More confidence — Teams using BDD are in general more confident that they will not break the code. They have better predictability when it comes to their work.
• Automation easiness — It’s very easy to turn scenarios into automation tests. The steps are already given by the scenarios. The automation engineer needs to write methods/functions to perform each step’s operations. Scenario outlines make it easy to run the same scenario with different combinations of inputs. This will reduce the code duplication, which is the bane of the automation and automation code becomes very modular.
• More adaptability — If the scenarios are simply written, they are very easy to update as the product changes. Modular design of the tests makes changes to automation code safer. Scenarios can also be filtered by tag name to decide what runs and what doesn’t. Scenario steps can be parameterized to be even more reusable and easy to adapt when it’s needed.

The more I think of BDD, the more I like it because it will enforce a quality-first and test-first mindset which is missing from a lot of projects. Quality becomes the responsibility of all the people involved in the development process. This will have a huge positive impact on the project. Developers and automation testers will think twice before writing their code. They will always start with “What’s the simplest thing that could make this test work?” which automatically helps them to write simple structured designed code. Too many developers don’t see the added value of this technique and/or don’t believe it works. But I say that until you put your hands and try it, you will not see the benefits and you will not understand it.

BDD and TDD are, in a way, psychological methodologies for enforcing people do the right thing in the right way when developing an application.

What they say is true: you DO get addicted to that nice green bar that indicates that your tests all pass. You want that color to be as green as possible, you want it always green, you want it to run as fast as possible, so you can quickly see it’s green…

Are there any challenges of implementing BDD? Yes, there are, and it all starts from the mindset and from the desire to implement it or not. There are a lot of advantages to this methodology, but there are also a lot of challenges you can encounter during the implementation. What is good is that if you truly understand the benefits, you will find a way to overcome all the challenges.

In summary, remember that the way BDD works is when all pieces — artifacts, process, and domain language come together. If one of them is missing, then you will not be able to see the BDD implementation benefits and most probably the attempts to introduce BDD will fail.

BDD is a powerful approach. In the right hands, it can make your customers happy by implementing exactly what they need and save your project a lot of money. However, BDD can be hard to adopt, because it requires changes to all levels.

The main prerequisite of BDD is having realistic expectations. Don’t expect to fix all your problems immediately.

This is a journey with a lot of challenges. While there are many success stories of teams that have implemented BDD, there are also many teams that have failed with BDD. Therefore, before starting this journey, a mitigation plan will help you to act and overcome all the difficulties before they have the opportunity to derail your well-intentioned BDD efforts.

There’s no doubt that the mindset shifted to quality-first and test-first that comes from following the BDD approach can have many benefits over time. The benefits listed in this article will hopefully convince you of that.

BDD is helpful, just try it and you will see all these benefits soon!

Get more insights from our engineering and design experts on our website!