INSIGHT ON BDD

WHAT IS BDD ?

Behavior-driven development (BDD) is an Agile development model that aims to solve communication issues by forcing developers and business leaders to speak in a shared language. Throughout the development process, teams maintain close communication with the client to ensure the most useful product or service is created. BDD ensures that all stakeholders have an active role in the development process so that all of their needs are met.

Behavior-driven development is an evolution of another Agile development model called test-driven development (TDD). TDD breaks down an application into functions. Developers then create tests to evaluate the code used for each part of the application.

Core Concepts Of BDD

Ubiquitous language

A ubiquitous language is a language that both the development team and the client agree upon. A shared language makes sure that there are no misunderstandings in the project. When the client tells the BDD team what is needed, the team will ask for examples that clarify the client’s needs. The examples will be communicated in the shared language. Gherkin is a keyword-based language that many teams use.

Given-when-then

When evaluating a client’s needs, BDD teams use a given-when-then model. “Given” describes the situation for a given example. “When” describes what an actor or stakeholder will do in the process. “Then” describes the outcome.

You can also use the terms “goals,” “actors,” and “impacts” to describe this concept, as well. Goals (given) are the missions that the project tries to complete. Actors (when) are developers, users, and anyone else who can affect when they act upon a project. The impact is the effect an actor has.

Value and complexity analysis

Value and complexity analysis is how BDD teams evaluate the importance of every operation in their project. Ideally, teams want to maximize the value they provide to their client while decreasing the complexity needed to complete a project.

How to write BDD scenarios

A BDD scenario is a written description of your product’s behavior from one or more users’ perspectives. Scenarios are designed to reduce the cost of translation and make it easier for your engineers to understand the requirements and for your QA (if you have one) to test it properly.

Using BDD scenarios means requirements and tests can be combined into 1 specification. In some cases, the scenarios that are written can then be easily converted into automated tests. BDD scenarios tend to follow a specific format. The format is fairly straight forward, and with a little practice you’ll be able to write your own.

In order to explain how BDD and scenarios work in practice, let’s take a look at the example of a user signing up to LinkedIn.

Example – signing up for a LinkedIn account

Here’s a basic BDD scenario which describes the LinkedIn signup process:

Scenario 1: User successfully creates a LinkedIn Account

· GIVEN John is on the LinkedIn Registration page

· WHEN he enters all required registration fields

· THEN a LinkedIn account is created

Let’s take a look at what’s going on here.

The first thing you’ll notice is the header ‘Scenario 1: user successfully creates a LinkedIn Account’. All written BDD scenarios should be given a header which accurately describes the scenario you’re interested in. You may have a few scenarios to assist your engineers / QA team and without headers things can get messy.

The second thing you’ll notice is the use of 3 words: GIVEN, WHEN, THEN. They don’t necessarily need to be in capital letters

GIVEN, WHEN, THEN

In its simplest format, there are 3 key elements in any BDD scenario:

GIVEN (describing the context) WHEN (describing the action) THEN (describing the outcome)

These 3 elements help to describe the behaviour of the system using context, actions and outcomes. If you have more than one or you require more information than this, you can add them with AND.

Using ANDs

When you require more information in a scenario, an ‘AND’ can be used after any of the descriptors:

GIVEN (context), AND (further context), WHEN (action/event), AND (further action/event), THEN (outcome) AND (further outcome)

Make sense?

OK, let’s revisit our LinkedIn registration scenario and flesh it out in more detail with a few ANDs.

GIVEN John is on LinkedIn Registration page WHEN he enters all the required registration information AND he hits ‘join now’ THEN his LinkedIn account is created AND he is directed to the profile creation page AND his confirmation email is sent

How do BDD scenarios work with user stories?

Your BDD scenarios should form part of 1 specification. This includes both the user story and the scenarios. So, for example, if you’re writing a user story in Jira you could structure your specification in Jira in the following order:

1. User story – start with the user story describing the requirements from a user’s perspective

2. BDD scenarios – then include your scenarios describing the behaviour of the system to assist with testing

A user story has a slightly different structure to your BDD. Your user story should comprise the following:

As an X I can / want Y So that Z

Using our LinkedIn example:

As a new user (John), I can register a new account on the homepage so that I can access LinkedIn.

Your BDD scenarios would then follow:

Scenario 1: User successfully creates a LinkedIn Account

GIVEN John is on LinkedIn Registration page WHEN he enters all the required registration information AND he hits ‘join now’ THEN his LinkedIn account is created AND he is directed to the profile creation page AND his confirmation email is sent

If you have multiple scenarios, you’d add these after Scenario 1 in a sequence.

Behavior Driven Development - Tools

· Cucumber (Ruby framework)

· SpecFlow (.NET framework)

· Behave (Python framework)

· JBehave (Java framework)

· JBehave Web (Java framework with Selenium integration)

· Lettuce (Python framework)

· Concordion (Java framework)

· Behat (PHP framework) etc

Behavior-driven development: Key benefits

BDD teams open differently and have different priorities than other types of development teams. There are several key benefits to having a BDD model. Knowing these will help you decide if a BDD model is best for your project.

Keep everyone involved and on the same page

Throughout the entire development process, everyone involved in a BDD team plays a collaborative role. BDD teams have regular short meetings (often daily) in which every member presents their progress from the day before, their plans for the current day, and what they’re having trouble with. A ubiquitous language also allows the client representative to be fully involved in the process.

Deliver functionality that users really need

Every initiative performed by a BDD team is designed to maximize the benefit to the user of an application. Because BDD teams can follow and evaluate the typical behavior of a user, they can identify areas where user experience can be improved and operations can be optimized.

Every action that a BDD team takes is appraised by the value it brings to the client of the software user.

Eliminate wasted time

In an Agile work environment, the work that you don’t do is just as vital as the work that you do. An ultimate goal of a BDD team is efficiency. To increase efficiency, the team must make sure it’s only performing the actions that are absolutely essential to its mission. BDD teams are always evaluating the value and complexity of their operations. If an operation is extremely complex but offers little value, it’s scrapped.

Summary

BDD lets us develop, test and think about the code from the view of the business owner. You need to have the mindset to implement ‘real time examples’ rather than implementing just ‘functionalities