I’ve just put a new system live, that I’ve been developing over the past few weeks. Basically its a document approval system. One set of users fill in a form, more users approve or reject it, finally one team signs it off and takes the document to the next system. Very simple.

I started well and designed a framework that I thought was nicely extensible. I wanted to avoid having to create the backend ever again, and simply plug UI and workflow approval definitions on top.

I decided that the UI would be pointless to test (initially) and so created unit tests for the backend. By using Linq to SQL I discovered that I could create a blank empty database every time I ran the tests as part of an Assembly level setup method, which considerably reduced my mocking needs. Okay it removed them. I built a complete set of unit Tests to cover the interaction as I saw them going through an entire lifecycle of every process I could think of.

Given such a good start, I have to admit that my final result is not impressive. As I moved into the UI layer I stopped running the tests (we don’t use CruiseControl). We discovered that there wasn’t just one big document, but it actually made more sense as two. This required quite a big change to the Engine and Database layers to handle this but unfortunately the unit tests stayed off.

As the application was small it was incredibly easy to test that the new design worked as planned without using the tests. I am used to an automated build / test runner, so I just carried on. Now as I come to run them again I find I can’t remember what the tests were supposed to do

Enter Behaviour Driven Design or BDD. BD seems to be TDD with a new name and a better way of constructing your tests to make them readable. It follows a grammar that allows business types to get involved.

As a <role> I want to <goal> so that <motivation>.

Given <assumption> when <action> then <test>

At this point I’ve only read about it but Scott Bellware’s article  seems to be the best. There also tool support but none of it seems to go from specification to code.

Update: Dan North’s article is better http://dannorth.net/introducing-bdd