I came across behaviour-driven development (BDD) early this year at the software architecture workshop in Cortina.
When Dan North started illustrating the concept and his findings, I almost immediately felt that he was on to something with incredible potential; so much in fact, that I definitely consider that session the highlight of the entire workshop.
On the surface, BDD can be described as a simple refinement of test-driven development (TDD).
After practicing TDD for a while, it is easy to realize that test-driven development is more about code design (specification) than testing (validation).
In fact, it is about expressing the behavioural intent of the systems we are developing.
As a consequence, BDD is a practice that, at its core, advocates modifying the nomenclature of our tests to better support this mindset.
There is a lot more to it of course, but since I still have to prepare my luggage and I risk to be late for my flight to Barcelona (yep, I’m going to Tech-Ed Developers!) I won’t go into any detail today.
I will write about it very soon, however, as I’ve been trying it for a while and I think it is only fair to share my experience.