{"id":85,"date":"2019-06-17T19:26:42","date_gmt":"2019-06-17T19:26:42","guid":{"rendered":"https:\/\/www.bddtesting.com\/?page_id=85"},"modified":"2019-06-17T19:26:42","modified_gmt":"2019-06-17T19:26:42","slug":"are-the-benefits-of-bdd-worth-the-effort","status":"publish","type":"page","link":"https:\/\/www.bddtesting.com\/are-the-benefits-of-bdd-worth-the-effort\/","title":{"rendered":"Are the Benefits of BDD Worth the Effort?"},"content":{"rendered":"\n

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.<\/p>\n\n\n\n

In this article I want to focus on the benefits and limitations of the BDD approach.<\/p>\n\n\n\n

What is BDD<\/strong><\/p>\n\n\n\n

BDD\u2019s 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\u2019s needs and the system\u2019s expected behavior.<\/p>\n\n\n\n

The following two examples demonstrate the difference between BDD and the traditional functional approach.<\/p>\n\n\n\n

A simple BDD test scenario:<\/p>\n\n\n\n

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

The code implemented with traditional functional approach:<\/p>\n\n\n\n

LoginPage loginPage = new LoginPage()\nloginPage.login(\u2018User\u2019)\nMainPage mainPage = loginPage.submitForm()\nmainPage.verifyPage()<\/code><\/pre>\n\n\n\n

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.<\/p>\n\n\n\n

BDD vs. traditional functional tests<\/strong>
Let\u2019s 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<\/a><\/p>\n\n\n\n

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.<\/p>\n\n\n\n

You can consider Karate Test Framework for API testing; the code looks very readable and clear:<\/p>\n\n\n\n

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

What you get with BDD testing<\/strong>
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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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