Appendix A: Notes to JUnit

A.1 Frequently Asked Questions (FAQs)

This short list of frequently asked questions was originally based on the FAQs contained in the JUnit documentation. The official JUnit FAQ list [URL:JUnitFAQ] has completely changed meanwhile. The following questions will be answered:

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

• How do I organize my test case classes?

• How do I run setup code once for all my test cases?

• I get a ClassNotFoundException when I use LoadingTestRunner. What can I do?

• Why do I get exception XYZ when using a graphical test runner, but not in the textual test runner?

• "assert" has been a keyword since JDK 1.4. Isn't there a conflict with JUnit's assert method?

• How do I best integrate JUnit with my favorite development environment?

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("ArrayIndexOutOfBoundsException expected");    catch (ArrayIndexOutOfBoundsException expected) {    } } 

Alternatively, you can use the ExceptionTestCase class:

1. Make your test case class a subclass of junit.extensions.ExceptionTestCase.

2. Write the test ignoring exceptions:

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

3. Create the test case:

    Test t = new ExceptionTestCase(    "testIndexOutOfBoundsException",    ArrayIndexOutOfBoundsException.class); } 

Chapter 4, Section 4.5 includes extensive instructions for testing of error cases and exceptions.

How Do I Organize My Test Case Classes?

This question was answered in detail in Chapter 3, Section 3.3, Organizing and Running Tests.

How Do I Run Setup Code Once for All My Test Cases?

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();    suite.addTest(...);    ...    TestSetup wrapper= new TestSetup(suite) {       public void setUp() {          oneTimeSetUp();       }    };       return wrapper; } 

A practical example can be found in Chapter 9, Section 9.5. Kent Beck argues that the need for a one-time setup is often a sign of a design in need of improvement (see [URL:YahooJUnit], Message 2789), especially when the test cases depend on one another.

I Get a ClassNotFoundException When I Use LoadingTestRunner. What Can I Do?

LoadingTestRunner uses its own class loader implementation to reload your code by default upon each test run. But this class loader does not include any standard classes and no classes from JAR files. You can specify a list of packages excluded from the default class loader so that they will be reloaded only once. This list is defined in the file excluded.properties in the junit.runner package. In the original file that comes with JUnit Version 3.8, all JDK-owned packages are excluded:

 # # 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.* excluded.5=java.* excluded.6=org.w3c.dom.* excluded.7=org.xml.sax.* excluded.8=net.jini.* 

If you are using libraries as JAR files, you have to add the packages included in these files to the exclude list. To this end, you either change the original file in junit.jar or you create your own file of junit.jar in the class path. In this way, your version will be loaded instead of the original file.

Why Do I Get Exception XYZ When Using a Graphical Test Runner, But Not in the Textual Test Runner?

Normally LoadingTestRunner is to blame. You can either adapt the exclude list as described in the preceding FAQ, or you can disable the Reload option. Considering that the Java class loading behavior causes very difficult problems, in rare cases only disabling the Reload option or using the textual test runners helps.

"assert" Has Been a Keyword Since JDK 1.4. Isn't There a Conflict with JUnit's Assert Method?

assert(...) was deprecated in JUnit Version 3.7. All calls should be replaced by assertTrue(...).

How Do I Best Integrate JUnit with My Favorite Development Environment?

Probably the most rudimentary form of integration is to simply make junit.jar available in the class path. This works in all cases, but starting a test runner may be more complex. Eclipse [URL:Eclipse] even comes with its own, seamlessly integrated JUnit test runner.

In addition, Ward Cunningham's Wiki includes a separate page about JUnit and IDEs [URL:WikiJWI]. This pages refers to tips, tricks, and problems relating to JUnit in connection with Forte, NetBeans, Kawa, MicrosoftTools, JBuilder, VisualAge, and Emacs. You can find a TogetherJ integration at [URL:ExtremeJava].