A UML Testing Framework

By: Martin Fowler

One of the UML’s primary benefits is that its diagrams help you explain how any system works. In this article, I’ll show you how to use UML diagrams to explain a small testing framework. I’ll illustrate some of the more important UML diagrams and discuss how I chose which framework parts to illustrate.

The system I’ll cover is JUnit, a lightweight testing framework for Java. JUnit was written by well-known object-orientation megastars, Kent Beck and Erich Gamma. It is a simple, well-designed framework. You can download the source code from the World Wide Web via my homepage at http://ourworld.compuserve.com/homepages/martin_fowler. You may find the source code useful for this article. If you program in Java, JUnit will improve your programming productivity by writing self-testing code. JUnit comes with documentation on how to use it.

The Packages
First, I’ll look at the packages that make up JUnit, illustrated in Figure 1. I refer to Figure 1 as a package diagram—but the UML does not actually define such a diagram. Strictly speaking, the diagram is a class diagram, but I’m using a set of class diagram constructs in a particular way. The class diagram style is what I call a package diagram.

The package diagram’s principal focus is the system’s packages and their dependencies. The diagram shows that the test package consists of three subsidiary packages: textui, ui, and framework. Each package contains a number of classes. Both textui and ui have a TestRunner class. Java packages and dependencies map easily to the Java package and the import statement. The essential idea is more wide-ranging, however. A package is any grouping of model constructs; you can package use cases, deployment nodes, and so forth. I find a package of classes the most useful. Dependency, in general, is used to show that a change in one element may cause a change in another. Hence, the diagram indicates that if I change the framework package, then I may need to change the textui and ui packages. However, I can change the textui package and not worry about any other package changing.

In a large system, it is particularly important to understand and control these dependencies. A complex dependency structure means that changes have far-reaching ripple effects. Simplifying the dependency structure reduces these ripples. The package diagram does not do anything on its own, but by helping you visualize the dependencies, it helps you to see what to do.

You’ve probably noticed that I have left many things out of the diagram. I haven’t mentioned a few classes in the JUnit packages. I’ve shown a dependency to java.awt, but left out dependencies to things like java.io and java.util. Is this sloppy diagramming? I don’t think so. You should use diagrams to communicate the most important things. I left out classes and dependencies to most of the Java base libraries that I don’t think are important. I’ve made an exception for awt because that line illustrates those classes that use a GUI. Choosing what is important is difficult, yet it is essential for any designer. All elements of a system are not equal. A good diagram reflects this.

Class Diagram of the Framework Package
Of the three packages in JUnit, the most interesting is the framework package. Figure 2 shows a class diagram of this package. I call this a specification perspective class diagram because I’m looking at the classes from their interface rather than their implementation. I know this because I drew the diagram based on the javadoc files, not on the underlying source code.

Full article...

Other Resource

... to read more articles, visit http://sqa.fyicenter.com/art/