Does BDD Testing Live Up to its Hype?

BDD, or behaviour-driven development, is a hot topic of late. In a nutshell, this approach creates executable, yet easy-to-comprehend tests from natural language phrases. This article will explore the advantages and disadvantages of a BDD testing strategy.

BDD’s fundamental function is to afford stakeholders the chance to understand all facets of a project by using straightforward language instead of hard-to-read code. That is to say, this BDD testing approach allows to build tests that depict the system’s anticipated behaviour as well as the users’ needs.

Below you can see a basic BBD test scenario and a piece of code that has been implemented with the traditional functional approach. The difference in readability is visible at first sight, isn’t it?

A basic BDD test scenario.

Code that has been implemented with the traditional functional approach.

From this example, it’s obvious that a BDD test is easier to understand and allows all members of the team to get to grips with whatever requirement or function is being tested. When it comes to Agile, we are able to clearly show what each automation script covers, in terms of acceptance criteria, user story or feature. Consequently, producing BDD test scenarios demands considerable more effort.

Traditional functional tests vs. BDD

Let’s look at a comparison of the traditional approach with BDD when using Cucumber, a tool that generates executable specifications.

Typically, behaviour-driven development is utilised for UI end-to-end testing; however, it is also appropriate for unit testing, such as Jasmine or Cucumber, performance testing and API testing.

The benefits of BDD testing

In addition to the easy-to-understand scripts, BDD offers a sizeable boost in project clarity, as well as the opportunity to cut down time spent on long-term endeavours. One of my biggest pet peeves is when only the engineer who executed a project’s tests can understand their results. BDD turns pages of hard-to-read code into text that is understandable by everyone, from managers and assistants to analysts and customers.

Of course, test implementation is not a project’s core activity; support and test execution generally takes longer than the initial test writing; however, if you take a look at the time and energy spent on investigating issues and analysing test results, it’s easy to see the benefit in being able to troubleshoot failed BDD scenarios quickly.

Being able to easily spot which step of a particular feature has fallen short and why, as well as being able to recognise a link between a business requirement and a failed test, puts you in a unique position when it comes to providing stakeholder feedback in a timely and understandable fashion.

Some limitations

Even though BDD testing offers a lot in terms of potential benefits, there are some drawbacks to take into consideration before opting to use the BDD approach for your next project:

• The code will demand a significant amount of time and effort to implement. For smaller, fast-paced projects, the overly verbose BDD approach is a bad fit. If your project’s development will cover complex user interactions and multiple product features and will take longer than six months to complete, then BDD is worth your consideration.
• Prior to setting up efficient BDD workflows, you need to have your project requirements well-defined, unless you want to devote additional time to clarifying app workflows and behaviours.
• Occasionally, the step definitions (Given/When/Then) may seem difficult to traverse. To make your life 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 panacea, but like any other technology, it can make a difference when it comes to the success of appropriate projects. If the list of statements below applies to you, BDD implementation should be your next step:

• My project has precise and well-defined business requirements.
• I need to share the project’s progress with management, stakeholders and project team members on a regular basis.
• My project will go on for more than six months.
• I favour a testing approach that is data-driven.

If you would like some assistance with your BDD project or if you have a question relating to what BDD can offer you, get in touch with us.

Originally published at eleks.com on July 5, 2018.