< Zurück | Inhalt | Weiter >

13.5.2 Running a Test Case

Recall how we ran the JUnit self-tests after installation. We can now use a similar command to execute our own test case. With the CLASSPATH still set as above, try compiling and running the test case:

$ javac net/multitool/core/AccountTest.java

$ java junit.textui.TestRunner net.multitool.core.AccountTest

The TestRunner will use introspection and reflection to dig information out of the AccountTest class. It will find all the public methods that begin with test and have no parameters. It will execute setUp(), then one of the test methods, then tearDown(); then setUp(), then another test method, then tearDown(), and so on. Our example has only one test method, testCreateSub(), so that will be the one test method it runs.

The result of running the test should look like this:

$ java junit.textui.TestRunner net.multitool.core.AccountTest


Time: 0.071

OK (1 test)



Quite likely, you’ll want to run several tests, exercising the various classes that make up your application. Let’s see an example of how to build such a suite of tests (Example 13.3).

While not defined as an interface, the convention is used by JUnit TestRunner classes that they will look for a public static method called suite() in any class that you ask a TestRunner to run. Your class, the one that will define the suite of tests, should return something that implements the Test interface. A TestSuite object is one such object, and we can fill it with tests gleaned automatically by JUnit from the class names that we supply.

We’ve also added a main() that invokes the text-based user interface for running these tests. That way you can invoke the tests from the command line if you like.

Here are the two commands to compile and execute the CoreTest suite, using the Swing GUI:

$ javac test/net/multitool/core/CoreTest.java

$ java junit.swingui.TestRunner net.multitool.core.CoreTest

When the GUI runs, click on the Hierarchy tab and you can see the vari- ous tests that make up the suite. Opening the folders will show the tests inside of suites (Figure 13.4).


Example 13.3 A suite of test cases

package net.multitool.core; import junit.framework.*;

public class CoreTest

extends TestCase


public CoreTest(String str)



} // constructor CoreTest


* Constructs a collection of tests to be run by the TestRunner.


public static Test suite()



* Add the results of each separate Test into a big Suite.


TestSuite suite = new TestSuite("Core Classes"); suite.addTestSuite(net.multitool.util.SAMoneyTest.class); suite.addTestSuite(AccountTest.class); suite.addTestSuite(UserTest.class);

return suite;

} // suite

public static void main(String [] args)



} // main

} // class CoreTest



Figure 13.4 The CoreTest running a suite of tests

One last example is the SAMoneyTest.java file that was used in the CoreTest example (Figure 13.4). Did you notice the names displayed in the test hierarchy? They don’t match the method names used to run the tests in SAMoneyTest.java because we constructed the suite “by hand” instead of letting the JUnit introspection and reflection find the methods dynamically.

Such manual approach has some advantages. You can restrict the current set of tests being executed to a subset of the entire set of tests. You can also, as this example shows, give other names to the tests. The biggest drawback, though, is the maintenance cost of having to add the test by hand to the suite() method whenever you add another test method.


We have shown you how to download JUnit and get it running. We have dis- cussed creating a test case and creating a suite of tests. We’ve looked at the Swing GUI for JUnit but also at the command-line interface. We have shown how our design translates to a minimal code implementation from which we can begin testing. We’ve discussed the “design, test, then code” approach, and how you can use it to track the progress of your implementation.


JUnit can be invoked from ant. It is an optional task (not part of the standard ant release), but easy to install and get running. Both the junit.jar and ant’s optional tasks JAR file need to be in your classpath. That’s all it takes. See http://ant.apache.org/manual/OptionalTasks/junit.php for more details.

JUnit integrates well with Eclipse and other IDEs. It is easy to install and very easy to use when it’s part of your IDE. For whichever IDE you choose, get the JUnit plug-in for it and use it.

One area we haven’t yet discussed is how to do unit testing for the GUI portion of your application. The basic idea is the same. In order to manipulate your GUI from the test, you may want to investigate the java.awt.Robot class. It can be used to generate system input events such as mouse and keyboard actions.

In fact, we’ve only begun to describe the various ways that JUnit can be used for all kinds of testing. Our focus has been on unit tests during code devel- opment, but JUnit can also be applied to integration and release testing. With any large Java application, it is crucial to have a good set of regression tests that can be rerun after features or fixes are added, or after classes have been refactored. JUnit has proven to be very valuable in these situations.

Finally, remember that JUnit is only a tool. The GIGO law2 tells us not to expect great tests just because we know how to run a tool. Test design, like any good design skill, is art as well as science. Learning the art of testing will pay dividends in better code built faster.


2. Garbage In, Garbage Out.


13.10 Exercises 313


Visit http://www.junit.org/ for all things JUnit-y, including some docu- mentation (though it’s not the greatest) and scores of articles which provide tons of useful information.

A very good article on JUnit appeared in the May/June 2003 issue of Oracle magazine (online at http://otn.oracle.com/oraclemagazine), titled “A JUnit Step-by-Step,” by Michel Casabianca.

For more about software testing in general, there is a classic (that is, from early days of computing) book on the subject: Glenford J. Myers, The Art of Software Testing, Wiley, New York, 1979.

You may also want to check out Just Enough Software Test Automation by Daniel J. Mosley and Bruce A. Posey (ISBN 0-13-008468-9, 2002). Their Web site3 includes a bibliography of nearly hundred articles and books on client-server and other software testing topics.


How many other tests can you think up to add to the AccountTest class? Did you include checks for bad behavior—for example, attempting to make too many subaccounts? Add the new asserts and rerun the test.


3. http://www.csst-technologies.com/csstbibl.php