JUnit Tests for Class Hierarchies
The Problem Of Interfaces
The Sun Java Tutorial indicates that classes which implement an interface "[sign] a contract" [SUN]. In some cases, the contract specifies terms for the contract beyond the API declared in the interface source-code, such as "must never return null", usually declared in the JavaDoc. Hence, the logic has moved from the code itself to the structure of the code [BG99].
The JUnit testing framework's design encourages good testing habits by moving much of the menial bookkeeping to the automated system, but it falls short in helping developers test situations such as the interface problem above. A common solution involves a manual cut-n-paste effort that relies more on the developer's memory than on automation.
The Problem of Antidecomposition
D.E. Perry and G.E. Kaiser [PK90] state in their not-so-obvious axiom of Antidecomposition that even if super-class methods are completely tested in the super-class, they still need to be retested in any subclasses, since the inherited methods exist in a different context.
Again, JUnit encourages the use of cut-n-paste code for testing subclasses, or the tests are simply overlooked [BMMM98]. Some developers attempt to subclass one test from another, but that solution does not scale when interfaces need tests as well. To develop robust tests, it seems the tests need a design just as much as the core software.
This JUnit extension contains the net.sourceforge.groboutils.junit.iftc package which has the explicit purpose to help developers write tests for such inherited logic (the GJE). It also helps reflect the source structure in the tests: if a class extends a class and/or implements an interface, then so do its test suites.
You can find out more about the GroboUtils JUnit hierarchy testing extention under the article on using the ITFC.
This space graciously provided by the SourceForge project
2002-2004 GroboUtils Project.|
All rights reserved.