Behavior-driven development, or BDD, is a trend much spoken about recently. In short, this methodology provides a set of best practices to translate natural language sentences into executable, yet easily readable tests.

In this article I want to focus on the benefits and limitations of the BDD approach.

What is BDD

BDD’s primary purpose is to provide a common understanding of project features for all the stakeholders and eliminate ambiguities from requirements. In other words, this approach helps to describe the user’s needs and the system’s expected behavior.

The following two examples demonstrate the difference between BDD and the traditional functional approach.

A simple BDD test scenario:

Scenario: User can log in to the web application
 Given I have opened web application "app.com"
 And I am on the login page
 When I type "User" credentials
 And I submit the form
 Then I should be redirected to the home page

The code implemented with traditional functional approach:

LoginPage loginPage = new LoginPage()
loginPage.login(‘User’)
MainPage mainPage = loginPage.submitForm()
mainPage.verifyPage()

From the example, we can clearly see that a BDD test example is more readable and allows everybody from the project team to understand what function or requirement the test aims to verify. In terms of Agile, we can clearly define what feature, user story, and acceptance criteria is covered by each automation script. Naturally, writing BDD test scenarios requires some more efforts.

BDD vs. traditional functional tests
Let’s compare the traditional approach to test implementation with the BDD on the example of Cucumber, a tool to create executable specifications./api/v1/uploads/44890/^712B7142FFEA76B33C4EDDD52F20F30BBFDCF351832386D61C^pimgpsh_fullsize_distr.png

Traditionally, behavior-driven development is used for UI end-to-end testing, but it is also applicable for such types of testing as Unit, Performance, and API.

You can consider Karate Test Framework for API testing; the code looks very readable and clear:

Feature: Test User API
    Scenario: Get all users
        Given url 'some-api.com/api/users'
        When method GET
        Then status 200
        And assert response.length == 2
        And match response[0].name == 'FirstUser'

What you get with BDD testing
Aside from the improved readability of scripts that can be reached with BDD, this approach can dramatically increase visibility and clarity on the project. Also, it can save time on long-term projects. From my experience, one of the major pains of a project is that only the engineer who implemented the tests can interpret their results in a correct way. BDD makes reports understandable for everyone, including managers, analysts, and clients.

Certainly, test implementation is not the central activity on the project. Usually test execution and support take much more time than writing all the tests. If you calculate the efforts spent on issue investigation and test results analysis, you can see that troubleshooting of failed BDD scenarios is very fast. You can easily detect what step of what feature has failed and why. Accordingly, you can establish a relationship between a failed test and a corresponding business requirement. After that, you can provide feedback to stakeholders and answer the questions about what features do not work as expected and what functions are end-user ready.

A few more things to consider
Although BDD testing has a lot of benefits, there are some limitations you might want to consider while choosing a methodology for your project:

  • You will dedicate considerable amounts of time and effort to the implementation of the code. For small, fast-paced projects, the wordy BDD approach is redundant. Consider using BDD if the development will cover multiple product features and complex user interactions and will last longer than six months.
  • To set up effective BDD workflows, you must have your project requirements strictly defined. If they are not, expect to spend extra time on clarifying app workflows and behaviors.
  • Sometimes, the step definitions (Given/When/Then) may seem hard to navigate. To make things easier, you can use IDE plugins, like VSCode Cucumber, that open the code behind the steps or help to autocomplete them.

Summary
BDD is not a silver bullet, but like any other technology or approach it can add up to the success of the appropriate projects.
If you agree with most of the affirmations below, you should really consider implementing BDD:

  • My project has clear and well-defined business requirements;
  • On a regular basis, I need to share clear results of the project’s progress with all team members, stakeholders, and management;
  • My project will last longer than six months;
  • I plan to use a data-driven testing approach.

  • https://www.utest.com/articles/are-the-benefits-of-bdd-worth-the-effort