Behavior driven development (BDD)

What is BDD?

Behavior driven development(BDD) is a software development process based on test-driven development (TDD) and it combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software developers and business analysts with shared tools and a shared process to collaborate on software development, with the aim of delivering “software that matters”.

How it is developed:

Behavior driven development was developed by Dan North as he encountered some issues(specified below) in test-driven development:

Where to start in the process
What to test and what not to test
How much to test in one go
What to call the tests
How to understand why a test fails

Benefits of BDD:

Teams are already using TDD or ATDD may want to consider BDD for some strong reasons:

BDD offers more precise guidance on organizing the conversation between developers, testers, BA and product managers.
It uses very easy laguage that we speak everyday like what, how, where etc.
BDD tools automatically generates technical and end user documentation from BDD “specifications”

Writing BDD Stories:

It is much structured enough that we could break the story into its constituent fragments and automate them. We started describing the acceptance criteria in terms of scenarios, which took the following form:

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


Let’s use the classic example of an ATM machine. One of the story cards might look like this:

Title: Customer withdraws cash
As a customer,
I want to withdraw cash from an ATM,
so that I don’t have to wait in line at the bank.

So how do we know when we have delivered this story? There are several scenarios to consider: the account may be in credit, the account may be overdrawn but within the overdraft limit, the account may be overdrawn beyond the overdraft limit. Of course, there will be other scenarios, such as if the account is in credit but this withdrawal makes it overdrawn, or if the dispenser has insufficient cash.

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

Scenario 1: Account is in credit
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned

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

Scenario 2: Account is overdrawn past the overdraft limit
Given the account is overdrawn
And the card is valid
When the customer requests cash
Then ensure a rejection message is displayed
And ensure cash is not dispensed
And ensure the card is returned

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.

Acceptance criteria should be executable:

The fragments of the scenario – the givens, event, and outcomes – are fine-grained enough to be represented directly in code. JBehave defines an object model that enables us to directly map the scenario fragments to Java classes.

You write a class representing each given:
public class AccountIsInCredit implements Given {
public void setup(World world) {

public class CardIsValid implements Given {
public void setup(World world) {


and one for the event:
public class CustomerRequestsCash implements Event {
public void occurIn(World world) {


and so on for the outcomes. JBehave then wires these all together and executes them. It creates a “world,” which is just somewhere to store your objects, and passes it to each of the givens in turn so they can populate the world with known state. JBehave then tells the event to “occur in” the world, which carries out the actual behaviour of the scenario. Finally it passes control to any outcomes we have defined for the story.

Gopal Das
Follow me

Gopal Das

Founder at GopalDas.Org
He is a technology evangelist, Salesforce trainer, blogger, and working as a Salesforce Technical Lead. After working in Java based project implementation, he jumped to the Salesforce system on a whim and never looked back. He fell in love with Salesforce’s flexibility, scalability, and power. He expanded his knowledge of the platform and became a Certified App Builder, Administrator, Platform Developer I, SalesCloud Consultant while leading the Salesforce implementation and technology needs. He has worked in a wide variety of applications/services like desktop, web and mobile applications.
Gopal Das
Follow me

Leave a Reply

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