Behavior Driven Development (BDD)



Behavior Driven Development is an Agile software development process that encourages collaboration among developers, QA and non-technical or business participants in a software project. It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave. It emerged from test-driven development.

Principles of BDD

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

  • define a test set for the unit first
  • make the tests fail
  • then 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. BDD is a continued development of TDD which makes more specific choices than TDD. Behavior driven development specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit. The desired behavior consists of requirements set by the business.

BDD specifies that business analysts and developers should collaborate in this area and should specify behavior in terms of user stories which are each explicitly written down in a dedicated document. Each User Story should, in some way, follow the structure given below :

An explicit title.
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

A brief example of this format may look like this :

Title: Returns and exchanges go to inventory.

As a store owner,
I want to add items back to inventory when they are returned or exchanged,
so that I can track inventory.

Scenario 1: Items returned for refund should be added to inventory.
Given that a customer previously bought a black sweater from me
and I have three black sweaters in inventory,
when they return the black sweater for a refund,
then I should have four black sweaters in inventory.

Scenario 2: Exchanged items should be returned to inventory.
Given that a customer previously bought a blue garment from me
and I have two blue garments in inventory
and three black garments in inventory,
when they exchange the blue garment for a black garment,
then I should have three blue garments in inventory
and two black garments in inventory.


Leave a Reply

Your email address will not be published. Required fields are marked *