Monday, 11 February 2008

What does the B in BDD mean

Hmmm ... the B in BDD. I know what it's supposed to stand for. So what does it smell like? A bit like a bad Balti. You know the one. It smells good when you're all beered up and you need a good dose of ghee to line your internals, but in the morning you'll smell like stale spice and hate yourself.

I've heard of TDD being described as "poor mans formal methods". Well BDD as it’s currently being hawked is "poor mans formal methods sold by a snake oil salesman".

As a general rule of thumb, I reckon you can judge the substance of an idea by the use cases put forward as exemplars of the idea.

Is this:

stack."should be empty"

demonstrably better on any level in any universe than:

assert stack.isEmpty()

Actually this is the best explanation I've seen of why all this BDD (frameworks at least) stuff does not seem amazingly compelling to me.

As a branding exercise BDD may well be a good suggestion. It might be a good idea to drop the "Test" from TDD, since the word "Test" encumbers us with the idea that it is something you do after everything else is done. It’s the implementations that seem a bit stilted to me.

You could use any xUnit framework for all and any of its short comings, coupled with well thought out tests to specify the behaviour of the software under test.

It is true xUnit tests do not communicate nicely with the business end of a software project, but are these BDD frameworks aimed at providing a fancy way to expose the intent of tests in human readable form? Perhaps that’s an unfair question since clearly the intent is really about moving from
from business requirements in the direction to working code.

So would using a BDD framework be a good approach to driving development. For the sake of argument lets imagine we were able to get “Behaviour” style user stories from “the business” in the format:

Given some context …
When some condition and/or action happens …
Then this other thing happen or be true …

It looks to me that if we could get something like the above, then our problems would be over. We'd have some concrete unambiguous requirements! To get to this point we would already have had to define a constrained format for the requirements. Then we would still need to implement a translation layer to map those requirements to a verification language, with or without a framework. That language would then be able to assert that the system meets the requirements.

If the BDD frameworks are just another mechanism for writing the verification language, fair enough but they do not allow us to move up to a higher level abstraction. They do not provide us with the means to write this:

Given some context …
When some condition and/or action happens …
Then this other thing happen or be true …

and then just automatically get the computer to just do the right thing. Therefore I can’t see the compelling argument for the adoption of any the current rash (rSpec, jBehave, Instinct, easyb ... and so on and on) of BDD frameworks.

I have no deep love for Fit, having used it a bit too much recently, but I can say this. It enables us to our say to our clients something not a million miles away from this:

Given a trade that looks like this …
When you amend it as follows …
Then the resulting trade will be like this …

Job done.

We can do this in some quite flexible ways and one thing I do know for sure is that our clients have never shown any interest in the behaviour of the Stack object which I know must be lurking somewhere in the code.