History

SpringUnit's origins lie in my desire to remove test data values from test source code and move them to an external XML file where they could be reused. Joerg Gellien's DDTUnit does a very nice job at this and I wrote numerous unit tests of POJOs using this excellent framework.

When I wanted to do integration testing - particularly of data access objects and business logic objects that were wired together using Spring - I ran into a limitation. Spring includes a framework of test classes that handle the wiring of objects defined in bean configuration files, with and without transaction support. The Spring classes and DDTUnit both require extension to create tests, yet with single inheritance one or the other must be selected. Therefore, obtaining the benefits of Spring's dependency injection and DDTUnit's data-driven tests required either extending DDTUnit and adding Spring capablities or extending the Spring test classes and emulating DDTUnit's data-driven approach.

I chose the second approach for two reasons. First, Spring builds the test data once per test class (vs. per test method), so this is faster. Second, and more importantly, using Spring's bean configuration schema makes adoption and use easier for more developers, since many are now already familiar with that file format.

After developing SpringUnit, I found a reference to Robert Newson's Spring-enabled test case, which shows example code and accompanying commentary. Discovery of Newson's work validated many design decisions in SpringUnit, such as file/class naming conventions and the use of reflection to construct and retrieve data values. Because it is a published framework, SpringUnit adds value because it is distributed as a jar file and it comes with documentation, Javadocs, a tutorial, cookbook and complete case study demonstrating its use in a variety of testing scenarios.