Behavior Driven Development (BDD)

by Adam Sandman on

What is BDD?

Behavior Driven Development (BDD) is a methodology of software development that combines the principles of test-driven development and Domain-driven design. It was developed to help teams create software that is more user-centric, easier to maintain, and more reliable. BDD focuses on the user experience and allows teams to quickly identify and address issues that arise during the development process.

Although BDD emerged from the Test-Driven Development (TDD) approach that was pioneered in agile methodologies such as Extreme Programming (XP), it is not really about testing. BDD is first and foremost a methodology for capturing requirements in a way that expresses the behavior of the requirement. It is often used in conjunction with a user story to define not just the what the feature is meant to do, and why it is beneficial but also all the different ways that feature can be tested.

How Is a BDD Requirement Written?

A Sample BDD requirement would be:

Title

An explicit title.

Narrative

A short introductory section with the following structure:

  • As a: the person or role who will benefit from the feature;
  • I want: the feature;
  • so that: the benefit or value of the feature.

Acceptance criteria

A description of each specific scenario of the narrative with the following structure:

  • Given: the initial context at the beginning of the scenario, in one or more clauses;
  • when: the event that triggers the scenario;
  • then: the expected outcome, in one or more clauses.

What is Gherkin Syntax?

Gherkin is a business readable language which helps you to describe business behavior without going into details of implementation. It is a domain specific language for defining tests in a standardized format for specifications. It uses plain language to describe use cases and allows users to remove logic details from behavior tests.

In addition to being a useful way of describing a requirement specification, the text in the Gherkin language acts as both documentation and the skeleton of your automated tests. The Gherkin format is based on TreeTop Grammar which exists in 37+ languages. Therefore, you can write your Gherkin test in 37+ different spoken languages.

An example BDD requirement specification written in Gherkin would be:

Feature: Login functionality of social networking site Facebook.

Given I am a facebook user.

When I enter username as username.

And I enter the password as the password

Then I should be redirected to the home page of facebook

Benefits of BDD

The primary benefit of BDD is that it encourages communication between developers and other stakeholders, such as product owners and users. BDD helps bridge the gap between technical and non-technical stakeholders by providing a common language for discussing behavior of the system. By using this language, stakeholders can understand each other’s needs and expectations, leading to better development decisions.

BDD helps teams to quickly identify areas of improvement in their software. By focusing on user behavior, BDD encourages teams to think about how users interact with their software and how they use it. This helps teams to quickly identify areas that need improvement and identify potential problems with user experience.

BDD is also beneficial for ensuring quality throughout the development process. By focusing on user behavior, teams can quickly identify and address any issues that arise during the development process. This helps to ensure that the software is reliable and meets the needs of the users. BDD also helps teams to quickly identify areas of improvement in their software, which improves the user experience.

Additionally, BDD helps teams to create software that is easier to maintain. By focusing on user behavior, teams can quickly identify areas of improvement, which makes it easier for teams to quickly improve their software and make changes as needed. This helps to ensure that their software is up-to-date and can be maintained easily.

Finally, the use of Behavior Driven Development (BDD) is an effective way to ensure that the software is developed in the way that is expected by the customer. It encourages collaboration between developers, testers, and stakeholders, and helps to ensure that everyone is on the same page with regard to the desired behavior of the software. BDD also helps to improve the efficiency of the development process and reduce the chances of errors and defects.

Drawbacks of BDD

Although using BDD has many advantages, it should be noted that it’s not a panacea, and there are several disadvantages that should be borne in mind:

  • Complexity: BDD can be a complex methodology to understand and implement, especially for teams new to the approach.
  • Time consumption: Creating comprehensive and detailed feature files can be time-consuming, and this increased level of documentation can slow down the development process.
  • Over-specification: The focus on detailed feature descriptions can lead to over-specification, which can limit creativity and flexibility in the development process.
  • Maintenance: BDD requires ongoing maintenance of feature files, which can become a burden as the project progresses and requirements change.
  • Dependence on collaboration: BDD relies on effective collaboration between developers, testers, and business stakeholders, and this can be difficult to achieve in practice.
  • Tool support: While there are many tools that support BDD, not all are equal in terms of functionality and ease of use, and finding the right tool for a given project can be challenging.

Implementing BDD in SpiraTeam

As mentioned in the sections above, a key success factor for implementing a BDD approach in your team is to make sure you have effective processes and tools in place that foster and open, collaborative approach between your developers, testers, designers, and other stakeholders.

In addition, the tools you use should encourage simple, easy to write (and change) BDD scenarios rather than a rigid set of formatted documents and hard to maintain feature files. Otherwise, you end up with a waterfall-like set of prescriptive requirements, rather than a truly agile methodology.

SpiraTeam from Inflectra offers a complete, integrated agile requirements and project management platform that is ideal for defining user stories and BDD scenarios as well as easily using the scenarios to create test cases and integrate with automated testing tools. SpiraTeam encourages a test-first approach to development which maximizes the value of using BDD and infuses quality in each step of the requirements and development process.

In this next section we outline different ways you can implement BDD using SpiraTeam

1. Using Gherkin Feature Files

As described in this news article, one of the simplest ways of implementing BDD is to write them as Feature files, managed in the Documents section of SpiraTeam.

SpiraTeam includes a special Gherkin text editor that lets you easily write the plain text Feature files using the standard Gherkin syntax:

Then when you save the file, SpiraTeam has a built-in syntax highlighter and preview capability:

In addition, you can then link these BDD Feature files to other artifacts in SpiraTeam, including requirements, user stories, and test cases:

One benefit of this approach is that you can easily access the files using the Documents REST API that is part of SpiraTeam. This can be used by automated testing frameworks to programmatically access the feature files.

SpiraTeam provides robust editing and versioning of the Feature files that means you can make changes and then revert back to a previous version if you need.

The one major drawback to this approach is that you need to manage the feature files separately from the main SpiraTeam requirements and test cases, so it is not as integrated as our second option.

2. Using Requirements with Scenarios

Instead of using separate feature files in the SpiraTeam Documents module, a better option in many cases is to use the main requirements section, and simply enable the use of the Scenario section for the user story requirement type:

Once you have enabled this for the requirement type, each user story will now have a set of definable steps as well as the primary Description field.

In this example, we have written the title of the SpiraTeam requirement in the format of a standard user story – “as a [x] I can [y] so that [z]”. This ensures that we cover the who, what and why of a requirement:

  • As a product template admin [who]
  • I can set the statuses that show on the Spira task board [what]
  • So that product teams can use the boards more efficiently [why]

However, by itself, this is missing the “how”. That is where the scenarios steps come in. Each BDD scenario is written as step in the requirement. For example:

Scenario: accessing the requirement status page

Given I am a template admin for a template

When I open the template admin menu

Then I see a link to “Status” in the requirement section

And clicking the link opens the Status page for requirements

Using this approach, we can natively use the requirements feature in SpiraTeam to write user stories and associated BDD scenarios in a simple, easy to maintain formation. However, there is also a bigger benefit when it comes to writing the associated test cases.

3. Creating BDD Test Cases

Inside SpiraTeam there is a great time-saving feature that will let you create a test case directly from this BDD scenario in one click. Simply choose the option to create a test case from the requirement in the Test Coverage tab:

When you click this button, SpiraTeam will create a BDD style test case automatically:

You now have a test case that is derived from the specified user story and BDD scenarios. This lets testers easily verify that the requirement works as expected, and meets the needs of the customer.

Integrating With Automated Test Frameworks

The final refinement is to use the BDD scenario to implemented an automated testing process. You can of course simply use the Rapise test automation tool from Inflectra, which will automatically pull the test cases from SpiraTeam in the BDD syntax.

In addition, two popular open-source frameworks that make use of Gherkin are Robot Framework which can be integrated with SpiraTeam using our Robot Framework integration, and Cucumber, which can be integrated with SpiraTeam either using our Java jUnit plugin, Ruby::Unit plugin or via. Rapise.

How do I Get Started?

To learn more about SpiraTeam and how it can improve your agile software development processes please:

Spira Helps You Deliver Quality Software, Faster and with Lower Risk.

Get Started with Spira for Free

And if you have any questions, please email or call us at +1 (202) 558-6885

Free Trial