I am working on evaluating a Business Rule Management System at work - namely, Drools. As such, I expect that my posts in the near future will be about Drools in particular, or BRMS in general.
However, for the last several months, I have been doing some straight forward development in .NET. Every new task I got, that could be decoupled from some existing system, I saw as an opportunity to experiment with a new testing approach. Some peers led me to the following article, which gives a great approach to thinking about testing, and provides a syntactic framework (i.e. great convention) for writing unit tests: Behavior Driven Development.
The general idea is to test the way your units behave, rather than testing for specific output. Breaking a system into small behavioral pieces and then basing tests on whether some action happened or not, seems to solve the problem of typical unit tests, where we try to figure out which inputs and outputs prove that a requirement has been met. The tests are meant to be executable specifications and should be constructed so that they can be read like plain English: "when I'm walking, my right leg should move at the same rate as my left leg". In order for this to occur in the test environment, the test class names and the test methods are written to reflect the desired sentence.
For the example above, the context is the test class: when_walking, and an observation in that context, is a test method: the_right_leg_should_move_at_the_same_rate_as_the_left_leg
Interestingly, this is pretty much the syntax and method by which business rules in a BRMS are written. I love the bridge that this approach creates between business requirements, testing, and implementation.
