JUnit Frequently Asked Questions

How do I implement a test case for a thrown exception?

I get a ClassNotFoundException when I use the LoadingTestRunner

How do I run setup code once for all my TestCases?

How do I implement a test case for a thrown exception?

Catch the exception and if it isn't thrown call the fail method. Fail signals the failure of a test case. Here is an example:

public void testIndexOutOfBoundsException() {
    Vector v= new Vector(10)
    try {
         Object o= v.elementAt(v.size());
         fail("Should raise an ArrayIndexOutOfBoundsException");
    } catch (ArrayIndexOutOfBoundsException e) {
    }
}

or use the ExceptionTestCase as follows.
1) make your TestCase class a subclass of ExceptionTestCase.
2) write the test ignoring exceptions

public void testIndexOutOfBoundsException() {
Vector v= new Vector(10);
v.elementAt(v.size());
}

3) create the TestCase:
Test t= new ExceptionTestCase("testIndexOutOfBoundsException", ArrayIndexOutOfBoundsException.class)

Looking at this again, the first way is simpler. Sigh...

How do I organize my Test Cases?

Here is one way:

create a test package for each of your application packages. For example, for a package myapp.util define myapp.utiltest. Put all the fixtures for the util package into this package.
in myapp.utiltest define a class which creates a suite with all the tests in this package. To do so define a class AllTests which includes a single static suite method. Here is an example:

public static Test suite() {

TestSuite suite= new TestSuite();

suite.addTest(Fixture1.suite());

suite.addTest(Fixture2.suite());

return suite;

}

define similar AllTests classes that create higher level suites containing the suites from other test packages.

When the fixtures are in a separate test package the test cases don't have access to the methods and fields with default visibility ("package visible"). A variation of the above convention is to put all fixtures into the application package itself. This gives the fixtures access to all the package visible methods and fields. To separate the fixture classes from the production classes put them into a separate directory that you then add to the CLASSPATH. This makes it easy to ship the production classes independent of the fixtures. Here is an example for how to do this:

put the fixtures classes for myapp.util into a TESTDIR\tests\myapp\util directory,
add the tests directory to your CLASSPATH.

set CLASSPATH=%CLASSPATH%;TESTDIR\tests

How do I run setup code once for all my TestCases?

Wrap the top level suite in a subclass of TestSetup. Here is a sample AllTests.suite() method:

public static Test suite() {
TestSuite suite= new TestSuite();
...add your tests and suites here...
TestSetup wrapper= new TestSetup(suite) {
   public void setUp() {
    oneTimeSetUp();
   }
};
return wrapper;
}

I get a ClassNotFoundException when I use the LoadingTestRunner

The LoadingTestRunner uses a custom class loader to reload your code. This class loader doesn't attempt to load classes from jars or to load standard classes. Instead you can specify a list of excluded package prefixes that shouldn't be reloaded for each test run. The list of package prefixes is defined in the properties file junit.util.excluded.properties. As we deliver it this file excludes the packages that come with jdk1.2 from reloading:

#
# The list of excluded package paths for the TestCaseClassLoader
#
excluded.0=sun.*
excluded.1=com.sun.*
excluded.2=org.omg.*
excluded.3=javax.*
excluded.4=sunw.*

If you are using additional jars from 3rd party vendors you can either:

update this file in the junit.jar and add your package paths or,
"patch" the junit.util.excluded.properties file with the CLASSPATH, that is, put your customized version of this file in the class path before the junit.jar. In this way your version will be loaded instead of the one that comes with junit.

I want to debug when a test fails

Start the test runner under the debugger and configure the debugger so that it catches the junit.framework.AssertionFailedError. How you do this depends on the used IDE. Most Java debuggers support to stop the program when a specific exception is fired. Notice, that this will only break into the debugger when an "anticipated" assertion failed error occurs.