BDD

Learning BDD

In software engineering, behavior-driven development (BDD) is a software development process that emerged from test-driven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

BDD is largely facilitated through the use of a simple domain-specific language (DSL) using natural language constructs (e.g., English like sentences) that can express the behavior and expects outcomes. Test scripts have long been a popular application of DSLs with varying degrees of sophistication.

Cucumber is a behavior-driven development (BDD) acceptance test framework

First of all, Capybara, Acceptance test framework for Ruby web applications
Secondly, Behat, BDD acceptance framework for PHP
Subsequently, Lettuce, BDD acceptance framework for Python

History

Behavior-driven development is an extension of test-driven development: development that leverages a simple, domain-specific scripting language. These DSLs convert structured natural language statements into executable tests. The result is a closer relationship to acceptance criteria for a given function and the tests used to validate that functionality. As such it is a natural extension of TDD testing in general.

BDD focused on:

Firstly, Where to start in the process
Secondly, What to test and what not to test
Subsequently, How much to test in one go
In addition, What to call the tests
Lastly, How to understand why a test fails

Principles of BDD

At its core, behavior-driven development is a specialized form of Hoare logic applied to test-driven development which focuses on behavioral specification of software units using the Domain Language of the situation.

Test-driven development is a software development methodology which essentially states that for each unit of software, a software developer must:

First of all, define a test set for the unit first;
Secondly, implement the unit;
Finally, verify that the implementation of the unit makes the tests succeed.

This definition is rather non-specific in that it allows tests in terms of high-level software requirements, low-level technical details or anything in between. One way of looking at BDD therefore, is that it is a continued development of TDD which makes more specific choices than TDD.

Behavioural specifications

Following this fundamental choice, a second choice made by BDD relates to how the desired behavior should be specified. In this area BDD chooses to use a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design. Each user story should, in some way, follow the following structure:

Title: The story should have a clear, explicit title.

Narrative

A short, introductory section that specifies

Firstly, who (which business or project role) is the driver or primary stakeholder of the story (the actor who derives business benefit from the story)
Secondly, what effect the stakeholder wants the story to have
Subsequently, what business value the stakeholder will derive from this effect

Acceptance criteria or scenarios

a description of each specific case of the narrative. Such a scenario has the following structure:

First of all, It starts by specifying the initial condition that is assumed to be true at the beginning of the scenario. This may consist of a single clause, or several.
Subsequently, It then states which event triggers the start of the scenario.
Lastly, it states the expected outcome, in one or more clauses.

A very brief example of this format might look like this:

Story: Returns go to stock

In order to keep track of stock

As a store owner

I want to add items back to stock when they’re returned

Scenario 1: Refunded items should be returned to stock

Given a customer previously bought a black sweater from me

And I currently have three black sweaters left in stock

When he returns the sweater for a refund

Then I should have four black sweaters in stock

Scenario 2: Replaced items should be returned to stock

Given that a customer buys a blue garment

And I have two blue garments in stock

And three black garments in stock.

When he returns the garment for a replacement in black,

Then I should have three blue garments in stock

And two black garments in stock

This format is referred to as the Gherkin language, which has a syntax similar to the above example. The term Gherkin, however, is specific to the Cucumber, JBehave and Behat software tools.

Specification as a ubiquitous language

Behavior-driven development borrows the concept of the ubiquitous language from domain driven design. A ubiquitous language is a (semi-)formal language that is shared by all members of a software development team — both software developers and non-technical personnel. In this way BDD becomes a vehicle for communication between all the different roles in a software project.

The example given above establishes a user story for a software system under development. This user story identifies a stakeholder, a business effect and a business value. It also describes several scenarios, each with a precondition, trigger and expected outcome.

Specialized Tooling Support

Much like test-driven design practise, behavior-driven development assumes the use of specialized support tooling in a project. Inasmuch as BDD is, in many respects, a more specific version of TDD, the tooling for BDD is similar to that for TDD, but makes more demands on the developer than basic TDD tooling.

Tooling principles

In principle, a BDD support tool is a testing framework for software, much like the tools that support TDD. However, where TDD tools tend to be quite free-format in what is allowed for specifying tests, BDD tools are linked to the definition of the ubiquitous language discussed earlier. The exact implementation of this varies per tool, but agile practice has come up with the following general process:

To begin with, the tooling reads a specification document.
Secondly, the tooling directly understands completely formal parts of the ubiquitous language (such as the Given keyword in the example above). Based on this, the tool breaks each scenario up into meaningful clauses.
Subsequently, each individual clause in a scenario is transformed into some sort of parameter for a test for the user story. This part requires project-specific work by the software developers.
Lastly, the framework then executes the test for each scenario, with the parameters from that scenario.

Tooling examples

There are several different examples of BDD software tools in use in projects today, for different platforms and programming languages.

Possibly the most well-known is JBehave, which was developed by Dan North. The following is an example taken from that project:

Consider an implementation of the Game of Life. A domain expert (or business analyst) might want to specify what should happen when someone is setting up a starting configuration of the game grid. To do this, he might want to give an example of a number of steps taken by a person who is toggling cells. Skipping over the narrative part, he might do this by writing up the following scenario into a plain text document (which is the type of input document that JBehave reads)

Given a 5 by 5 game

When I toggle the cell at (3, 2)

Then the grid should look like

…..

..X..

…..

When I toggle the cell at (3, 1)

Then the grid should look like

…..

..X..

When I toggle the cell at (3, 2)

Then the grid should look like

…..

..X..

The bold print is not actually part of the input; it is included here to show which words are recognized as formal language.This code must be written by the developers in the project team (in Java, because that is the platform JBehave is based on). In this case, the code might look like this

private Game game;

private StringRenderer renderer;

@Given(“a $width by $height game”)

public void theGameIsRunning(int width, int height) {

game = new Game(width, height);

renderer = new StringRenderer();

game.setObserver(renderer);

}

@When(“I toggle the cell at ($column, $row)”)

public void iToggleTheCellAt(int column, int row) {

game.toggleCellAt(column, row);

}

@Then(“the grid should look like $grid”)

public void theGridShouldLookLike(String grid) {

assertThat(renderer.asString(), equalTo(grid));

}

The code has a method for every type of clause in a scenario. JBehave will identify which method goes with which clause through the use of annotations and will call each method in order while running through the scenario. The test code provides an implementation for each clause type in a scenario which interacts with the code that tests and performs an actual test based on the scenario. In this case

Firstly, the theGameIsRunning method reacts to a Given clause by setting up the initial game grid.
Subsequently, the iToggleTheCellAt method reacts to a When clause by firing off the toggle event described in the clause.
Lastly, the theGridShouldLookLike method reacts to a Then clause by comparing the actual state of the game grid to the expected state from the scenario.

Story versus specification

A separate subcategory of behavior-driven development forms tools that use specifications as an input language rather than user stories. Specification tools don’t use user stories as an input format for test scenarios but rather use functional specifications for units that are being tested. These specifications often have a more technical nature than user stories and are usually less convenient for communication with business personnel than are user stories. An example of a specification for a stack might look like this

Specification: Stack

When a new stack is created

Then it is empty

When an element is added to the stack

Then that element is at the top of the stack

When a stack has N elements

And element E is on top of the stack

Then a pop operation returns E

And the new size of the stack is N-1

Since they are seen as alternatives to basic unit testing tools like JUnit, these tools tend to favor forgoing the separation of story and testing code and prefer embedding the specification directly in the test code instead. For example, an RSpec test for a hashtable might look like this

describe Hash do

let(:hash) { Hash[:hello, ‘world’] }

it { expect(Hash.new).to eq({}) }

it “hashes the correct information in a key” do

expect(hash[:hello]).to eq(‘world’)

end

it ‘includes key’ do

hash.keys.include?(:hello).should be true

end

This example shows a specification in readable language embedded in executable code. In this case a choice of the tool is to formalize the specification language into the language of the test code by adding methods named it and should.

The result of test will be:

Hash

should eq {}

includes key

hashes the correct information in a key

Make your resume stand out and become a Certified Capybara Testing Professional. Try free practice tests here!

A great career is just a certification away. So, practice and validate your skills to become Certified Capybara Testing Professional