Behavior Driven Development (BDD)

Behavior Driven Development (BDD) was developed by Dan North. Behavior Driven Development (BDD) is a methodology for Software Development through communication between development team, product team and stakeholders. Communication between teams help to understand each feature correctly by all the members of the team before development process starts. Also help to understand the scenarios for each story also to reduce ambiguities from requirements, issues like:

  • Where to start the process?
  • What to test and what not to test?
  • What to call the tests?
  • How to understand why a test fails?


In Behavior Driven Development (BDD) Examples are known as Scenarios. Scenarios explain how should a feature behave in different situations. Scenarios are described in special language called Gherkin. Gherkin is a structured natural language that is used to specify how they want the system to behave for given scenarios. Gherkin serves two purposes: serving as project’s documentation and automated tests.

Gherkin Keywords:

  • Feature
  • Background
  • Scenario
  • Given
  • When
  • Then
  • And
  • But
  • *
  • Scenario Outline
  • Examples

For Example,

User Story: As a [role] I want [feature] so that [benefit]”

Now let’s describe the acceptance criteria in terms of the given scenarios,

Given [initial context],

When [event occurs],

then [ensure some outcomes]


This method involves both product team and development team on the same page with different perspective and makes sure all understand the expectation. The goal of BDD is to define the behavior of a feature through examples in plain text. These examples are defined before the development starts and are used as acceptance criteria also a part of the Definition of Done (DoD).



Feature: “Passenger confirms when dropped off by the driver”

As a Passenger,

I want to confirm when I have been dropped off, So that the trip shows completed


Using Gherkin:

Scenario 1: Successful dropped off by the driver

Given passenger requested for a ride

And has been picked up by a Driver

And passenger is on the way to the destination

When passenger arrived to the destination

Then passenger needs to confirm the drop off

And ensure that the trip is completed


Scenario 2: Driver never arrived

Given passenger requested for a ride

And passenger has not been picked up by the Driver

And Driver already started the trip

When passenger is asked to confirm the drop off

Then gets both confirm and reject option

And passenger can reject the drop off

And leave a message about the incident

Practicing BDD has the potential to bring big benefits to software development and software testing programs.


[Image from Google]

Leave a Reply

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