Behavior Driven Development can make your life more relaxing.

In agile methodology, when we talk about delivery then it’s all about customer satisfaction and acceptance. Recently, I presented a session in an open forum stating what Behavior-driven development (BDD) can actually do and how can we start applying BDD in our day-to-day development.

BDD is an interface between a coder and a customer. It turns a requirement into a simplified language, which everyone can understand, and then in the backend, the required work is done.

Generally, the requirements are not clear initially and then the costs incurred to add changes are more in the long run, say, at the time of delivery. The best part of this technique is that we can bridge the gap and have a common understanding of the Definition Of Done between all; coder, quality analyst, customer, end-user, business analysts. This applies to each and every person who is involved in the software development process right from the initial days to the delivery of the product.

In BDD, you have to specify the behavior into whole sentences, not just the naming and specifications, but also the code syntax. It focuses on exact and expressive sentences.

And just by going through the sentences, everyone who is involved in the product right from the beginning till the delivery can understand everything without going into the code. Also, once the test is written then the sanity testing is easier to write and maintain. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.

BDD is a Mindset not a Tool!

You must have read on web, BDD is an outsider in methodology, but how? Let me try and add my 2 cents in this context.

Actually, the development starts with uniting the business upshot and then digging into traits to attain the goal. Every feature is then encapsulated into STORY which defines the Definition Of Done associated with the feature to implement.

Where to start and how to apply?

We have an existing application, but:

It’s old
It’s not doing what we actually want it to perform.
We want the better implementation of the same application
We take good pieces
Throw out the bad pieces

Add some better pieces

Story Structure :

The structure of the story is not mandatory as long as you are following BDD concepts of doing work but I have seen in many projects people following the following template:

Title // (one liner description of the feature/story/activity)

Narrative: //The narrative should include a role, a feature and a benefit

As a [role]

I want [feature]

So that [outco…

And [another outcome]…

Scenario : … //The scenario should be described in terms of Givens, Events and Outcomes

Given some initial context

When a case occurs

Then there are different consequences.

The narrative is the story scope and actual work that needs to be done. It follows the same format of the story which XP has. Against each story, we can define the Definition Of Done associated with each story. Each story can have multiple scenarios and each scenario can have unique-GIVEN WHEN THEN along with multiple AND, OR.

“given” represents the state of an application at the starting of the test case.

“when” clause depict a mutuality among-st a user and an application.

“then” clause portray the status of the application after this interaction has done.

Scenario: Adding two numbers

Given a calculator

When I add the numbers 4 and 5

Then I see the result 9


public static void main(String[] args) {
		/*Given /^a calculator$/ do
			@calculator = Calculator.new
			end*/
		 Scanner in = new Scanner(System.in);

		/* When /^I add the numbers (\d+) and (\d+)$/ do |a, b|
		 @calculator.add(a.to_i, b.to_i)
		 end*/
	      System.out.println("Enter First Number:"); //say 4
	      String num1Str = in.nextLine();
	      System.out.println("Enter Second Number:"); // say 5
	      String num2Str = in.nextLine();

	     /* Then /^I see the result (\d+)$/ do |a|
	      @calculator.result.should == a.to_i
	      end
*/
	      int sumTotal = Integer.parseInt(num1Str)+Integer.parseInt(num2Str);
	      System.out.println("The sum total is:"+sumTotal); // say 10

	}

One can start picking a story as we do in the scrum. Story narration starts from the Product Owner, who actually defines a story. Further discussions can involve business analysts along with other team members say QA, developer, etc.

What can we achieve via BDD?

Business readable and executable.
Enable communication
Bound to implement.

Tools that support Behavior driven development:

Cucumber

Jbehave

Concordion
Twist
easyB
Fitnesse

These tools have wide scope among-st them and they support different languages like JAVA, Groovy, Ruby etc.

This is just an overview of the BDD technique, in which one can quickly start practicing it and feel the change in areas like productivity gain, scope, etc.

In the end, I would like to conclude that maybe BDD looks like a tedious task in itself but once you start practicing this approach then you can gradually feel the change not only in development but also in the delivery and understanding of the end product.

To conclude, Martin Fowler well said “I believe that the hardest part of software projects, the most common source of project failure, is communication with the customers and users of that software.” and BDD can very well helpful in sorting this out.