Behavior Driven Development (or BDD) is an Agile software development technique that encourages collaboration between developers, QA and non-technical or business participants in a software project.

The focus of BDD is the language and interactions used in the process of software development. Behavior-driven developers use their native language in combination with the ubiquitous language of Domain Driven Design to describe the purpose and benefit of their code. This allows the developers to focus on why the code should be created, rather than the technical details, and minimizes translation between the technical language in which the code is written and the domain language spoken by the business, users, stakeholders, project management etc.

Dan North created a story-level BDD framework for Ruby called rbehave which was later integrated into the RSpec project.
The focus

The practices of BDD include:

* Involving stakeholders in the process through outside-in software development
* Using examples to describe the behavior of the application, or of units of code
* Automating those examples to provide quick feedback and regression testing
* In software tests, using ’should’ to help clarify responsibility and allow the software’s functionality to be questioned
* Test use ‘ensure’ to differentiate outcomes in the scope of the code in question from side-effects of other elements of code.
* Using mocks to stand-in for modules of code which have not yet been written

Few Pros and Cons that you might realize once you start working with BDD

Pros:
* I like that when I break a test or when a test is broken on the build
server that we know which business case will fail. That means broken code
relates directly back to the bottom line.
* I like that for *certain* cases I can give the bdd specs to a PM type
figure to read and double check my sanity.
* When I’m on a BDD roll, I find it faster to create tests than when unit
testing since I can test in larger chunks.
* It’s great to wade back into some old tests and have them make perfect
sense after just reading the class and method names.
* I’m forced to think in terms of business value. If I go off to write a
bunch of code that I can’t think of specs for it makes me pause and realize
that my specs may not be needed by those who pay me.
* I get 80-90% of the value of BDD by using the same unit testing framework
I was using for vanilla TDD.

Cons:
* I’m forced to think in terms of business value. It’s a PITA trying to
figure out how to think in terms of specs vs. layers/units. This is a mixed
blessing but ultimately, especially when first starting out, I wouldn’t say
you would want to force everyone to write in this style because it could
cause some serious velocity issues.
* It can be difficult to find specs you care about if you don’t name the
files/folders in your spec project properly. Right now there is no brilliant
guidance on the best way to do this either.

Let me know your views on this and if there are any practical expereinces

Neeraj
Senior Project Manager