The Inner Life of a Test Framework

As mere users of a test framework, we should not bother about its internal structure, unless we are programmers and, as such, interested in the inner parts of each piece of software we can get a hold of. In addition, unit testing is such an individual activity that we may sometimes not get around expansions and adaptations of the framework. JUnit does not cover every functionality anyone may need during testing; it is an open core that can be expanded and completed in different places. And if we find that JUnit limits our own test needs too much, then it may still serve us as an example for the benefits and drawbacks of certain design decisions in the development of our own test support tools.


So far, we have introduced three classes: TestRunner (in three different variants), TestCase, and TestSuite. But JUnit has much more in store. The inner structure of JUnit—mainly the package junit.framework—is a small tutorial in itself for the use of a large number of design patterns [Gamma95]. Kent Beck and Erich Gamma [Beck99] describe the patterns used and their motivation. [1] The article and the accompanying study of the JUnit sources is recommended to everyone and is an absolute must for all who want to understand and expand JUnit, even though JUnit has been further developed in the interim.

Screenshot shows a small section from the inner life of JUnit Version 3.8. Except for TestDecorator, this class diagram shows a section from the junit.framework package. What is new for us are the "extension hooks" for project-specific and functional expansions of the JUnit framework:

Java Click To expand
Screenshot: JUnit class diagram.

Knowing how JUnit is built inside is very useful, especially when you decide to start peeking behind the TestCase scene to enjoy some well written source text of the framework. [1]This article is included in the JUnit documentation as cookstour.htm.