Make your life simple with BDD.

n agile methodology, when we talk about delivery then its all about the 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 are 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 the exact and expressive sentence.

And just by going through the sentences , every one 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 better implementation of 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.

Narrative is the story scope and actual work which needs to be done. It follows the same format of 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.

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.

Recommended books: The Rspec Book and the Cucumber Book.