Behaviour Driven Design

Tom Adams’ Better testing through Behaviour on the topic of Behaviour Driven Development. BDD is an offshoot of “Test Driven Development” and Domain Driven Development. The central idea is that you first specify the behaviour that you’d like your code to have, in the form of tests, and then implement that specification.

Tom presented a bunch of examples from his Instinct Java test framework. Instinct differentiates itself from JUnit by paying a lot of attention to producing readable test cases – readable in the sense that you can make sense of it in English. Because of this, the test cases end up more like specifications. In the example on the Instinct website, he has a class named “AnEmptyStack” that tests the behaviour of empty stacks. This class has a method named “mustBeEmpty” that tests that the stack’s isEmpty() method returns true. You would read this as, “An empty stack must be empty”.

In comparing to TDD and JUnit some of the points (I think I heard) Tom made were:

• xUnit tends to work only at the code level, whereas Instinct and BDD tend to work both on high level stories and at the code level.
• Instinct and BDD dosn’t guide you so much toward strict units of code, but into adding behaviour wherever it’s needed to support the specification. In cases where you do need very clearly defined APIs – such as when providing public APIs to distinct processes or libraries, you will need to take extra care.
• Instinct does tend to drive more usable APIs.
• Instinct makes for more readable tests than JUnit, and plays nicer with IDEs.
• Because of the language, Instinct is a valuable resource for developer-developer and developer-analyst communications.

I think I’d like to try Instinct on one of my home projects, then perhaps use it in the office.