Behavior Driven Development

What is Behavior Driven Development(BDD)?

If you have practiced Test Driven Development (TDD) is that BDD drives its value from principles of TDD (which focus on incremental design delivery) where the Software development team(Product owner, Business Analyst, Development and Testers) incrementally create common and shared understanding of the next most valuable behavior to build in the system to realize the best incremental value.

This required behavior is captured as specification in Acceptance tests and its scenarios and developed incrementally using BDD with focus on Behavior of the System under envelopment not its implementation details.

BDD concepts and practices are promoted by Dan North, who realized the during his TDD training classes that TDD is too Test focused and has probkem. In his words –
“I had a problem. While using and teaching agile practices like test-driven development (TDD) on projects in different environments, I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails”

Definition from Dan North, the creater of the BDD approach is as follows:
BDD Descroption from Dan North during

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.

Simple Introduction
Let’s make it simple for everyone to understand. Let’s try to understand the follow question:

Assuming What happens between team members (Product owner, Developer , Test engineer) developing a User Story?

  –

BDD Practice

BDD is customer driven where customer describe the behavior of the application feature in natural language with the help of examples. Examples are elaborated using the GIVEN-WHEN-THEN scenario description techniques, which means GIVEN an initial context, WHEN the event occur, THEN the application should exercise the behavior.
These examples are automated and converted to Acceptance tests. 
Acceptance tests methods emphasize use of ‘should’ and ‘ensure’ keywords for describing the behavior of software to help clarify responsibility.

Example: For feature acceptance test

Scenario: Inventory should be checked for each item before confirming  an order

  • Given a customer has filled the shopping cart with an order of multiple items
  • and the inventory store is available for access
  • when he activates the request for the order placement
  • then all items in the order should be verified for availability in the inventory

public class OrderVerificationTest{

@Test
public void shouldEnsureThatOrderItemsAreAvailableInInventory() {
 Inventory invnt= MOCK(Inventory.class);
      
      Order order = new Order();
      order.addItem("item1");
      order.addItem("item2");

order.placeOrder(); //check if the invnt.checkAvailability(item) is called twice,once for each item in the order when placeOrder() is called; }}


What is the advantage?

Collaboration: BDD brings all customers (or PO, BA representations ) together in describing the behavior of the system.

Ease of implementation change: The behavior of the system under design and implemenation hardly chnages. Its the implmentation of the system behavior that can chnage. If the Behavior chareteristics are static, why not have them abstracted out in a structure which is independent of how the final implemnattion. This is great advantage of BDD. Think and

Ubiquitous language for stake holders:

Ease oif Refactoring:

Process of BDD:

Tools for BDD


1) Fitnesse
2) Twist
3) JBehave
4) Cucumber for Ruby
5) Rspec for Ruby
6) Specflow  for .NET
7) CBehave: A Behavior Driven Development Framework for C

Language for BDD:

Given:
When:
Then:

Following are some good links on BDD:
1) Introducing BDD by  Dan North.
2) BDD is Like TDD by Dan North.
3) Short description of BDD  – BDD in Nutshell by Rachel Davies
4) Wikipedia page on BDD.
5) Liz Keogh’s blog on BDD
6) IBM article. Very good example driven introduction of BDD – In pursuit of code quality: Adventures in behavior-driven development
7)  BDD approach to defining and identifying stories – Whats in a story?
8) Good stackoverflow discussion
9)  Another small example for JBehave BDD users by Giordano Scalzo’s Personal Blog
10) Good Presentation slides on  BDD and JBehave by Nikolay Vasilev.
11)

2 thoughts on “Behavior Driven Development

  1. victorleonard September 6, 2012 / 12:20 pm

    DD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology.in software development its used in every process so its very useful to enhance the projects.

    Like

  2. victorleonard September 6, 2012 / 12:50 pm

    DD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology.in software development its used in every process so its very useful to enhance the projects.

    Like

Leave a Reply to victorleonard Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s