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.
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.
... to read more articles, visit http://sqa.fyicenter.com/art/