Introduction to Behavior Driven Development

 Behavior Driven Development

Behavior Driven Development is an Agile software development technique focused on improving a key factor in the successful development of any software product: Communication. It is a technique devised by Dan North as a response to the issues he encountered whilst teaching Test Driven Development. Eric Evans describes it this way in his book Domain Driven Design: “A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of design… Across this linguistic divide, the domain experts vaguely describe what they want. Developers, struggling to understand a domain new to them, vaguely understand.”

He goes on to describe the concept of modeling a system using a ubiquitous language based on the business domain, so that the business vocabulary permeates right into the codebase. BDD seeks collaboration amongst the delivery team and business participants in a software project. On the “Agile specifications, BDD and Testing eXchange” in November 2009 in London, Dan North gave the following definition of BDD: “BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.”

It is a framework based on three Core Principles:

1. It’s All Behavior: Business and Technology should refer to the same system in the same way

2. Whereas The Business Value: Any system should have an identified, verifiable value to the business

3. Enough Is Enough: Up-front analysis; design and planning all have a diminishing return

Behavior Driven Development centers on obtaining a clear understanding of desired software behavior through discussion with stakeholders. From this initial discussion between the stakeholder or users and the business analyst comes a list of features of the system to be developed, features also known as “User Stories” in our Agile environment. They describe the behavior from the perspective of those interested in the product.

The format is:

As a [X], I want [Y], so that [Z]

Where X is the person (or role) who will benefit , Y is some feature , and Z is the benefit or value of the feature. Its strength is that it forces you to identify the value of delivering a story when you first define it. This can make it easier to descope some of the more esoteric requirements.

The next step is writing test cases in a natural language that non-programmers can read, specifying scenarios of system behavior. A scenario describes the feature acceptance criteria. We call scenarios “acceptance tests;” they express what the software needs to do in order for the stakeholder to find it acceptable. So, everyone on the team, including stakeholders, writes these tests collaboratively, because they not only decide the system behavior, but they learn how to describe that behavior in a common language that everyone understands. If the system fulfills all the acceptance criteria, it’s behaving correctly; if it doesn’t, it isn’t. So a template can be created to capture a story’s acceptance criteria.

The template had to be loose enough that it wouldn’t feel artificial or constraining to analysts but structured enough that we could break the story into its constituent fragments and automate them.

The next step is to automate these scenarios as examples, taking the following form:

Given – some initial context (the givens)

When an event occurs,

Then ensure some outcomes.

Acceptance tests written in this style become more than just tests: they are executable specifications and living documentation. When the software system is continuously validated against a set of executable specifications, the team ensures that the system will do what the specifications say. Or, to put it differently, the specifications will continue to describe what the system does.

They have the following benefits:

• Living documentation replaces all the artifacts that teams need for delivering the right product.
• We can continue defining specifications as the system grows up, in an incremental way.
• They are cheap to write.

To illustrate, a classic ATM can be used as an example:

Title: Customer wants to withdraw 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

There are many scenarios that we can 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, but let’s use the given-when-then template for an example.

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 card is returned

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.

Tools Used:

There are many tools available to in the market to implement the procedure. Following are tools which we use for BDD.

1. JBehave

2. Cucumber

3. SpecFlow

4. Watin

More Details about Tools are on the way. Keep look in the same space for more details.