There seemed to be lot of confusion around BDD among people at #cukeup.
There where a lot of testers at the conference, and while Cucumber runs tests, that’s not all it’s about because BDD is not about testing.
So what is it? and where does Cucumber fit in?
What is BDD?
I first came across the term in 2005 while I was working for ThoughtWorks.
A couple of things he said about it caught my attention.
It’s the bastard son of Test Driven Development and Domain Driven Design
It’s the nearest thing you’ll find to a silver bullet
I really liked the first statement, this was exactly what we needed.
I liked the second statement too but the most important part of it is “nearest thing you’ll find”. It’s not actually a silver bullet – there are none – hence the title of this blog.
At this point I set about trying to find out what it was all about. I didn’t know who Dan was at the time as he was never in the office. Then I got my next gig and I was never in the office.
I did find out more when I talked to Graham Brooks, who explained about Given,When,Then, then the penny dropped.
I started to try to write a BDD framework in C# with Rick Grundy called nDescribe but soon abandoned the attempt as C# is a horrible language to use to write an internal DSL.
I did finally manage to bump into Dan in the office but he was on the way out the door so we had a 45 second “is it…. …yep that’s it, gotta go” sort of conversation.
Time passed, I left ThoughtWorks and got into Ruby and along came rSpec, the rSpec story runner and then Cucumber and I loved it.
I loved it so much I insisted we wrote an in-house, very simplified .NET version of it, which we used for about 9 months, then along came SpecFlow, which was much better, and fitted in much better with our build pipeline so we moved over to that.
We wrote a lot of scenarios, and tried, and tried to get our BAs and QAs to get involved in writing them.
In short we were using it just as a test tool, a very flexible test tool, but we were missing out on the most important benefit of BDD, the collaboration across the various roles, and the shared understanding and shared language that brings (the DDD part).
We did eventually get the collaboration we needed and the benefits were great.
So I’m going to throw my hat into the ring with yet another definition.
BDD is about enabling the conversations that need to happen, at the right times, using examples as specifications to develop the shared understanding and shared language needed to deliver software that matters.
And what about Cucumber?
Cucumber (and SpecFlow etc.) and Given, When, Then are a useful way to capture the output from these conversations in an unambiguous format that helps the developers drive their development from the outside in.
But don’t forget to have the conversations – they are what counts.