Introduction

Part 1 is going to introduce you with the concept of Behavior Driven Development. Part 2 will consist a step by step instruction to build an application following Behavior driven development.

A brief history (or story) of almost all developers

Almost all developers like to do code more than they write test code. "Lets write the code first and meet the deadline and if time permits or if I feel OK then I would write some test code" - is a common mindset of almost each and every developer. Interestingly they all know the benefits of writing test code. Even a large percentage of them knows the benefit of adopting TDD (Test Driven development) toward software development life cycle. But still a very few can adopt TDD and continue with it.

Questions that raises in mind

The question is why the developers feel uncomfortable to write test code? Is there any way to over come this?

Problem with a real life example

Lets try to find the answers of these questions.

Lets assume that Mr. X is a hardcore .NET developer and he is going to develop a web based email program. His development manager or supervisor or product owner has given the specification of the email program like this.

Pretty simple specification!

Now Mr. X tries to follow TDD and he started to think what could be the possible test cases.

1. This program should send email if To address is valid.
2. This program should send email if CC address is valid even if To address is not valid
3.  This program should send email if BCC address is valid even if CC and To address is not valid.
4. This program should send email even if the subject line is empty.
5. This program should send email even if the body is empty.
   

Now after sorting out these 5 points he began to think that there might be some more test cases if the option stated in 1,2 and 3 altered. Even there might be more test cases if he considers the format of the body of the email (like plain text, rich text or html). If the body is HTML then he needs to thing about the html encoding things.

The more Mr. X, the hard core .NET developer gives to think to find possible test cases the more he finds test cases and one point like all other developers he may write few test cases or not any test cases by keeping in mind that -- "I will definitely write test cases once my functionality has been implemented".

But as usual at the end of the day almost no test cases has been written and the TDD vanishes!

Lets find the cure!

So far we have got the nature of the problem and its symptoms. Now lets start digging out a possible remedy of it.

What if the requirement given by the product owner or supervisor or development included the possible behavior of the module. To elaborate and to be more specific, if the requirement is given in such a way that fully expresses the behavior of the module and its possible corner points then it would be very easy to decide which test cases need to be written and which is not needed.

Researchers have spent lots of time to figure out a possible format of “requirement specification” that is easy to understand to both technical and non technical person. Experts term this type of language as Ubiquitous Language or Domain Specific Language (DSL). I am not going in to details of this thing but as i have already told that the purpose of this is to create a bridge between technical and non technical person.

Nowadays the word DDD (Domain Driven Design) is very popular and ubiquitous language or DSL is the first ladder of it. If you are interested to learn more about DDD then please Google the term DDD and enjoy your ride in DDD world!

You must be wondering that why I have brought ubiquitous language or DSL in the middle of solving a complex problem of every developers life? Fortunately this Common language type is going to solve our problem. You must be wondering how?

There are some good guys who actually developed such a language that can be written by any person regardless of technical background and that can be read and understood by any people on earth. Interestingly there are some parser for this language which can parse this plain English to compilable code of your favorite programming language.

Just one rule needs to follow, what ever you write use Given-When-Then steps. Confused? Its really very easy. Even I can write it, and I am writing the above requirements using this guide line.

Isn't it easy to write and read and understand? Isn't it covers and depicts all possible test cases? Hey! Isn't it actually writing a documentation of email module to be developed?

I know the answers of the above three questions are all YES! There is more exciting thing i would like to share with you, but before going in to that lets concentrate on the above specification to extract some more information that we need to know.

As you can see that along with Given-When-Then steps I have used and/or to bridge different specifications or corner points and you can actually add as many as possible combination of and/or in order to detailing your specification. And still it is completely readable to any human.

Oh! I forgot to mention the name of this language. It is known as Gherkin. You can visit this link to dig more information regarding this.
https://github.com/aslakhellesoy/cucumber/wiki/gherkin

Such type of requirement actually depicts how the module would behave once developed and developer can concentrate more on behaviour rather than writing test cases. Such phenomenon are termed as Behaviour Driven Development (BDD) and I am pretty sure you have understood the basic concept of BDD by now.

There are some tools (free of course) available that can actually parse specification written in Gherkin and can create test cases in your favorite language and isn’t it enough to trigger SayWOW event ;).

To implement BDD for .NET i have found Specflow (http://specflow.org/home.aspx) to be a cool tool that can be integrated with Visual Studio (even it supports VS 2010!). If you Google for more tool you will definitely find more!

For Java I have found Concordion (http://www.concordion.org/) to serve the purpose. But again by Googling you will get hell lot of tools.

In the second part I shall show you how you can implement BDD step by step in a .NET project.