Some Thoughts About BDD

Bob asked me about BDD.

“Behavioral Driven Design?” said I.

“Well… something like that… maybe…” he announced knowingly.

“I met it once” I stuttered.

“Think about it!” said our leader, and vanished in a puff of smoke.

So I thought about it.

The first problem I have with “Behavior Driven Development” is the name itself. Every time someone says it, I get confused. It’s a paradox. Like Military Intelligence.

Behavior is something you observe. A software behavior is driven by the way it was developed. Not the other way around. When I hear “BDD” I think that I need to develop something to behave in some way that will drive me to develop something. Then I must breathe into a paper bag.

Of course, what was actually MEANT is that someone will say how he wants the system to behave, and then the developer will do it. Which is actually what software development is all about, and I’m pretty sure it worked that way before 2006.

So what is the difference? The Givenwhenthen.

The Givenwhenthen is a magical creature. It has the head of a business-spec, the body of a unit-test, and the legs of a DSL. When you look at some of the frameworks developed to run it, be it a wiki with a “Test” button, or one of the cucumis sativus family, you get the feeling that what was given when Dan North spoke is much bigger than the product it drives.

Don’t get me wrong, I’m all for providing automated tests that describe the business requirements. I’m a big believer in TDD and ATDD. I also really like detailed business requirements. I just think that maintaining a specialized client just to write unit/integration tests is a nuisance more than a benefit.

A business analyst thinks of requirements in terms of acceptance details. In his mind he sees the client application, the end-user operation, and devises the best way this app will provide the business needs. He thinks about reports, and what kind of information should be there. He creates elaborate spreadsheets to verify the system actually works. He listens to client requests and deciphers what they actually need.

What a BA does not do is write code. And Givenwhenthen is code. Not because it must follow a syntax to fit a parser (which it does), and not because it does not work without writing code that gives it meaning (like most requirements) — it is because only a developer can write, modify and maintain it.

I was there. In the BDD zone. Writing structured semi-formal artifacts to represent behavior, and then writing adapters to pass it a quasi-business-model, that we hooked to the actual system, that was so far from the test at that point that you could never understand why it was red. At some point we just gave up. The effort was so big, we decided to spend it on developing the product itself. And the BA people never even looked at it. So we went back to TDD, and ATDD, and integration tests.

So yes. We are doing BDD now. Only it looks just like a unit test, and we call it integration. And when it is done right, it represents the expected behavior, and gives a good hint of the requirements… and here is my last reservation.

BDD worries me because it emphasizes behavior over requirements. And behavior changes from one client to another, even if it actually uses the same set of services. The FAEMA Enova allows dosed delivery programming, while the ZjNac F305 supplies seven premixed drinks. But both use the same water measurement service, because both need to handle the water volume for different behaviors.

If BAs will start writing unit-tests, we’ll be in a worse place than we were when Dan North presented the TDD challenge. The BA will have to ask themselves all these TDD questions, and might miss out on the Developer to Business-Expert dialog completely.

And then we can kiss DDD goodbye.