Understanding BDD

1. Introduction

A Behaviour-Driven Development (BDD) is a software development process oriented towards meeting the business requirements.

In this tutorial, we’ll analyze the BDD in detail. Moreover, we’ll introduce its ancestor, a Test-Driven Development (TDD). Finally, we’ll compare both.

2. TDD

BDD and TDD approaches share common elements. So, to fully understand BDD, we’ll need to briefly define a TDD. A test-driven development is a software development technique-oriented towards writing tests. Using TDD, we start by writing tests for features before implementing them.

2.1. Red/Green/Refactor

A TDD development cycle is often called red/green/refactor. Those are three crucial phases of TDD workflow.

The first phase is a red one. During it, we begin with writing a test for some part of the required feature. The test must fail because the feature isn’t implemented yet. If somehow the test pass, that means it’s badly written and should be corrected. Most of the IDEs inform about failing tests with red color messages. That’s why this phase is called red.

In the green phase, we write minimum code to make the test pass. The code quality isn’t important during that phase. The implementation should be quick and minimal just to cover the test.

In the last, refactor phase, we improve the code quality without changing the feature. Thus, after the clean-up, the test should still pass. While refactoring the code we should often execute the test. So, any potential errors could be easily spotted and corrected:

3. BDD

The main intention of BDD is to provide tools that allow technical and non-technical (business-related) people to effectively cooperate. Thus, the software is implemented basing on business requirements, especially user scenarios. Subsequently, BDD encourages natural, domain-specific languages with which all teams can easily work. Technically speaking, BDD is a combination of TDD and domain-driven design.

Let’s define the core concepts of BDD.

3.1. Fundamentals

There are three main rules of the BDD approach:

1. Enough is enough
2. Deliver value to stakeholders
3. It’s all behavior

The rules are straightforward. “Enough is enough” means that we should analyze, plan and design only what is really demanded. Moreover, we shouldn’t waste time specifying the full scope of the project at once as requirements will usually change over time. In other words, we should do only tasks necessary for the project to start, all other efforts are a waste.

A stakeholder is any individual or group who has an interest in the outcome project. Any activity related to the project must provide a business value. Thus, the second rule requires us to avoid any efforts that don’t deliver business value. Subsequently, any feature included in the project is considered valuable.

Finally, every participant of the project should be able to describe behavior at any level of the project (code, application, business) using ubiquitous language. The point is to shorten the gap between technical and non-technical people. Therefore, requirements are defined using user stories and scenarios. There exist specialized, business-readable languages for that purpose, like Gherkin.

3.2. Workflow

BDD consist of cycles of the following steps:

1. Identify business feature
2. Define scenarios and acceptance criteria for the feature
3. Determine steps per scenario
4. Write failing test steps for unimplemented feature
5. Write code to pass the test steps and
6. Refactor the code
7. Produce reports

Firstly, the stakeholder and business analyst discuss and identify the business needs. Then, together with the tester, they create stories. A story is a documented business requirement.

Each story should have a title, narration, and acceptance criteria. A narration defines feature description, its benefits, and the beneficent. As we already mentioned, the stories and their steps should be written in a business readable language. Let’s see a general form of the story:

Feature: [title]
    As a [role/beneficent]
    I want [feature]
    So that [benefit]

Let’s see a real-world example of a story for an online shop application:

Feature: Account registration
    As a client
    I want to register an account
    So that I don't need to enter my data with every purchase

Acceptance criteria specify when the story is complete. They are written in the form of scenarios that usually takes the following form:

Scenario: title
    Given context
    When event
    Then result

Let’s see a simple scenario for the earlier account registration feature:

Scenario: Email address validation
    Given I'm an unregistered user
    When I enter the email address on the registration form page
    Then the email address must be correct and not taken

When the stories and scenarios are ready we can start the red/green/refactor development cycle.

After the feature is implemented we can eventually generate test reports. There are specialized frameworks for various technologies that are used for BDD testing purposes, e.g., Cucumber, Serenity, Concordion, or Mocha.

After all, we repeat the BDD cycle for the next feature planned:

4. TDD vs BDD

First of all, BDD is oriented towards describing the project’s features as a behavior using ubiquitous language. So, it contributes to all partakers, both technical and non-technical. On the other hand, TDD focuses strictly on the implementation process. Thus, software developers are its main contributors.

Secondly, the BDD process starts with identifying business needs and writing stories and scenarios. So, the documentation can be easily understood by all project participants. In comparison, the TDD cycle starts with test implementation. Moreover, the crucial documentation is the tests themselves. Subsequently, the tests written in specific programming languages are readable only for technical people.

Following, BDD scenarios rely on end-users behaviors. Thus, they aren’t significantly impacted by any functional changes. Whereas in TDD, functional changes may affect a lot of test cases.

Finally, deployment of BDD could be more difficult and time-consuming. It requires collaborations of developers, testers, QAs, business analytics, and stakeholders. While TDD demands mainly a collaboration between developers. Still, the BDD cycle contains a TDD red/green/refactor process. Thus, the BDD process is a noticeably broader concept.

5. Conclusion

To sum up, BDD and TDD are different approaches. BDD is a good choice for projects heavily relying on end-users behaviors, e.g., e-commerce or application systems, like banking software, internet browsers, or games. In contrast, TDD will do well in projects like APIs or third-party frameworks, where BDD would be overwhelming or even hard to apply.