Tuesday, May 30, 2006

Organising Test Cases

One of my recent delvings into test driven code is how to ensure that all classes that implement an interface follow a given contract with the minimal amount of rework per class. In "Organising design-by-contract test code" it suggests creating "...abstract test cases for each of your (work) interfaces. These abstract test cases are specifically geared at testing the contract promoted by the (work) interfaces, and not things like setup, initialization or destruction code...Create concrete subclasses for these abstract test cases, which feed the superclass an instance of an implementation of the (work) interface that is being tested. These concrete classes are responsible for creating mock objects of the dependencies, doing any neccessary initialization, etc."

This is something I have used in the past, in something like JRDF there's abstract test cases that keep the creation of various objects hidden from the tests themselves.

My preference now is a little different - instead of using inheritance I use composition and I think that better reflects the flexibility of interfaces. Another advantage I've found is that ability to cross cut certain behaviours between these composed objects such as exception handling.

No comments: