Agile Business Coach

JBehave Q&A

Chris Wrote:

Dan

You are the man in the know when it comes to jbehave.

Someone on my blog has asked me why jbehave is so nifty.

My take is that instead of stating what test conditions a piece of functionality should satisfy, you are specifying the behaviour that the functionality should exhibit. This is a subtle difference that makes it easier to get responsibility driven design.

I know I've got this wrong so would appreciate why you think jbahave is nifty.

Regards

Chris

Dan North Wrote:

In the simplest case it is just a vocabulary change, to move away from the vocabulary of "tests" (it isn't a test - you haven't written any code to test yet!), so yes, you are exactly right. Also, the template word "should" encourages you to write proper sentences, so in your CustomerServiceBehaviour class, that accompanies CustomerService, you have methods like: shouldFindCustomerBySurname, shouldFindMultipleCustomers, shouldThrowExceptionIfNoCustomerFound, etc.

That leads on to agiledox-style documentation, so you can genuinely start writing self-documenting systems. Rather than junit TestCases, which have tests like testGetters, or testDatabase, which are just meaningless.

Also, if a responsibility (a "should" method) fails, you immediately know what the system should have been doing, rather than having to drill down into the method itself to find out what it does. Think of it like writing CRC cards in executable code. You define the Responsibility and Collaborations of a class as you go.

Posted by chrismatts at August 11, 2004 10:51 AM