Behavior Driven Development (BDD)

As companies start the agile maturation process and attempt the move to DevOps, one of the building blocks they need to incorporate is the use of a common language. The use of a common language is implemented in order to prevent teams and team members from misinterpreting (Drift) what their actual deliverables (critical behaviors) are. This common language is then used to drive the development of the CI/CD/DevOps infrastructure (In DevOps we test the infrastructure too) and the automated application testing. In addition, DevOps requires that an adequate test suite of automated tests be built out and that all parties have a high degree of confidence in these tests.

This is where Behavior Driven Development (BDD) and Acceptance Test Driven Development (ATDD) come into play (BDD/ATDD are also known as Specification by Example). BDD/ATDD provide a way to help build confidence in the automated tests, first by expressing all requirements in high-level business terms and then by automating these requirements in a way that provides a set of living/executable documentation detailing both which requirements were requested and how they have been implemented. Going forward, this living documentation provided by the automated specifications provides both a single source of truth about the application’s behavior and also a set of regression tests protecting it against unwanted change.

Behavior Driven Development (BDD) and Acceptance Test Driven Development (ATDD) are also seen as an evolution of Test-Driven Development (TDD) and are intended to make the TDD practice more accessible and intuitive to newcomers and experts alike. It shifts the vocabulary from being test-based to behavior-based, and positions itself as a design philosophy.

 

bdd_cycle

Behavior Driven Development (BDD) is a subset of Test Driven Development (TDD).

Please refer to our BDD course outline page for more information regarding BDD (also known as Specification by Example)

Test Scenario

Behavior Driven Development describes the acceptance criteria in terms of scenarios, which take the following form:

Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.

A story’s behaviour is simply its acceptance criteria – if your system fulfills all the acceptance criteria, it’s behaving correctly; if it doesn’t, it isn’t. In Behavior Driven Development the acceptance criteria is described in terms of scenarios.

Behavior Testing

Lets take a look at an example, let’s use the example of a Subway Ticket machine. A story card might look like this:

Title: Customer withdraws subway ticket
As a customer
I want to withdraw subway ticket from the machine,
so that I don’t have to wait in line at the ticket office.

So how do we know when we have delivered this story? There are several scenarios to consider: the machine must have tickets, the customer must provide payment, the customer must provide trip details. Of course, there will be other scenarios.

Using the given-when-then template, the first two scenarios might look like this:

Scenario 1: Machine has tickets
Given the machine has tickets
And the customer provides trip details
And the customer provides an acceptable form of payment
When the customer requests the ticket
Then ensure the ticket is dispensed
And ensure the payment is debited
And ensure the ticket works

Notice the use of “and” to connect multiple givens or multiple outcomes in a natural way.

Scenario 2: Machine is out of tickets
Given the machine is out of tickets
And the customer provides trip details
And the customer provides an acceptable form of payment
When the customer requests the ticket
Then ensure an out of tickets message is displayed
And ensure the payment is not debited

Both scenarios are based on the same event and even have some givens and outcomes in common. We want to capitalize on this by reusing givens, events, and outcomes.

To see an example of using Behavior Driven Development inside of a Selenium Test please see our demo using JBehave with Selenium.

 

logo-jbehave

XBDD is a tool to unite automated and manual test efforts. XBDD is a reporting tool that uses a combination of Cucumber json reports augmented with data from humans.

 

logo-jbehave

JBehave is a framework for Behaviour-Driven Development (BDD). BDD is an evolution of test-driven development (TDD) and acceptance-test driven design, and is intended to make these practices more accessible and intuitive to newcomers and experts alike. It shifts the vocabulary from being test-based to behaviour-based, and positions itself as a design philosophy.

 

logo-cucumber

Cucumber is a tool that executes plain-text functional descriptions as automated tests. The language that Cucumber understands is called Gherkin. While Cucumber can be thought of as a “testing” tool, the intent of the tool is to support BDD. This means that the “tests” (plain text feature descriptions with scenarios) are typically written before anything else and verified by business analysts, domain experts, etc. non technical stakeholders. The production code is then written outside-in, to make the stories pass.

 

logo-spinach

Spinach is a high-level BDD framework that leverages the expressive Gherkin language (used by Cucumber) to help you define executable specifications of your application or library’s acceptance criteria.

Download and extend ATF...

ATF Is Now Open Source

Join this 10 week program anytime...

DevOps Mastery Program

Get your DevOps health check now...

Free DevOps Assessment

X