Unit Testing with JBuilder Part III by Charlie Calvert

Copyright © 2002 by Charlie Calvert

This is the third part of a three part article .

Test Suites

After creating tests for the methods in Frame1 and StringBox classes we end up with two test cases, one called TestFrame1 and the other called TestStringBox. A test suite enables you to write code that will run both sets of tests at one time. The result is what you see in the message pane shown in Figure 8.

Figure 8: Running tests on both Frame1 and StringBox yields a hierarchy with two sets of tests.

It is easy to create a test suite in JBuilder enterprise. Indeed, it is easy to create a test suite by hand. In JBuilder, just choose File | New from the menu. Turn to the Test page of the Object Gallery and select the Test Suite wizard. On the first page of the wizard, use the add button to add both the TestFrame1 and TestStringBox classes to your test suite, as shown in Figure 9. Move to the next page and make sure that the package field is set to unittesting. This is the same drill that you went through with the TestStringBox class, so just follow the same procedure outlined earlier in the chapter.

Figure 9: Use the add button to add to your test suite the test cases that you want to run.

Press the Finish button to close the test suite wizard. The code that is generated looks like that shown in Listing 5.

Listing 5: A simple JUnit test suite.

package unittesting;


import junit.framework.*;


public class AllTests extends TestCase
{


  public AllTests(String s)
  {
	super(s);
  }


	public static Test suite() 
	{
		TestSuite suite = new TestSuite();
		suite.addTestSuite(unittesting.TestFrame1.class);
		suite.addTestSuite(unittesting.TestStringBox.class);
		return suite;
  }

}

You can see that a TestSuite object is created in the suite method of this class. Calls to addTestSuite on the suite object register with JUnit the test cases that we created. The end result is that all the tests in the TestFrame1 and TestStringBox classes end up being automatically called by this test suite, as shown in Figure 8.

NOTE: In other parts of the text I talked about the virtues of writing simple, easy to use classes. JUnit is an excellent example of the right way to architect a relatively complex set of classes.

Running JUnit tests from the Command Line

In this section of the text you will learn how to run test suites from the command line. Needless to say, this is the part of the chapter where the many people who use the personal version of JBuilder can learn how to run JUnit tests. As I said earlier, being able to automate tests from the command line is perhaps the preferred way to use JUnit, so you really are not missing much if you do not have the built in JBuilder tools.

NOTE: As mentioned earlier, the code shown above is simply standard JUnit test code of the type that all users of this open source project would use. JBuilder helps you generate the code automatically, but the generated code is just standard code for use with JUnit. You can therefore create a default JBuilder project as described at the beginning of this chapter. Insert the add and multiply methods shown at the beginning of this chapter into Frame1.java. Type in the JUnit code shown in listings 2, 4 and 5, or just find the same source files on the CD. Save the JUnit code in the same directory as Frame1.java, and then use it as described in the remaining sections of the chapter.

The open source JUnit code is stored in a file called junit.jar. This jar file ships with JBuilder in the /JBuilder7/lib directory. You can download up to date versions of that jar file from www.junit.org. The code found on junit.org is open source, so it is a free download with few strings attached.

NOTE: There is a license associated with JUnit source code, but it is not unduly restrictive. The code is meant to be used freely by developers in their day to day work. JUnit is released under IBM's Common Public License Version 0.5. If you are brave, you can read about the license here: http://oss.software.ibm.com/developerworks/oss/license-cpl.html. Here is one excerpt from this license: "Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusive, worldwide, royalty-free copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, distribute and sublicense the Contribution of such Contributor, if any, and such derivative works, in source code and object code form." I have no idea what this means, but it sounds like it might be something good.

The JUnit jar file comes with both a GUI interface to the test suites, and also a command line version. The GUI interface is good when you want to run the tests interactively, and the command line version is good if you want to integrate the tests into your build process. The output from the GUI interface to JUnit is shown in Figure 10.

Figure 10: A successful run of 16 tests against the StringBox class developed earlier in this book, as well as the Frame1 class created earlier in this chapter.

A sensible way to run the GUI tests is to ensure that codebox.jar and junit.jar are on your classpath. As you recall, codebox.jar comes on the CD for this book. You can also download it from www.elvenware.com. Change to the root directory for the UnitTesting project which we have developed in this chapter. Now issue this command:

java -cp .;%CLASSPATH%;classes junit.swingui.TestRunner unittesting.AllTests 

Though perhaps less sensible, the following code shows a bit more explicitly what is going on in the previous call:

java -cp .;g:/utils/classes/codebox.jar;g:/jb7/lib/junit.jar;classes 
	junit.swingui.TestRunner unittesting.AllTests

The variable %CLASSPATH% resolves at run time to the contents of your current classpath. My classpath is more complicated (or is it cluttered?) than the second example suggests, but I have pared it down so that you can see the important parts of the call.

Running Tests in Text Mode

If you want to run the tests in text mode, you can issue the following command:

java -cp .;%CLASSPATH%;classes junit.textui.TestRunner unittesting.AllTests

This command is nearly identical to the one for launching the GUI version of JUnit. In this case, however, you call junit.textui.TestRunner rather than junit.swingui.TestRunner. For those who want to work with older Java code, there is a junit.awtui.TestRunner.

Here is run of the text based version of JUnit:

[g:srcjavajbbookdebugunittesting]runTextTests.bat
java -cp .;g:/utils/classes/jaxp.jar;g:/utils/classes/codebox.jar;g:/jb7/lib/dx.
jar;g:/jb7/lib/dbswing.jar;g:/jb7/lib/jbcl.jar;g:/jb7/lib/junit.jar;g:/utils/cla
sses/mm.mysql-2.0.11-bin.jar;g:/Compilers/interbase/InterClient/interclient.jar;
classes junit.textui.TestRunner unittesting.AllTests
...GetFirstWord: OneWord
.GetFirstWord:
.GetFirstWord: Two
.GetFirstWord: A
...Data
Call: 01
Call: 001
IntToStrPad0: 001
.Data
......
Time: 0.5

OK (16 tests)

On the first line you can see the call to the batch file where I store the command shown at the beginning of this section of the text. The next chunk of code simply echoes the command back at us. In particular, you see the whole classpath, followed by the call junit.textui.TestRunner. Finally, you see the name of the class that holds the tests we want to run: unittesting.AllTests.

The references to GetFirstWord and IntToStrPad0, etc, are the output from various calls to System.out.println that I have scattered in my code. The next to last line with text on it shows how long the run of JUnit took, and the final line shows that all sixteen tests passed.

JUnit and Ant

A synergy has developed between an open source project called Ant and the JUnit project. The Apache Jakarta Ant project is a Java version of the make utility. Ant is much easier to use than make, and at least for Java development, it is much more powerful. In particular, it is easy to extend the functionality found in Ant.

Ant allows you to automate the process of building your applications. The synergy between Ant and JUnit stems from the fact that you can use Ant to automatically run the test scripts that you build with JUnit. In particular, you can make your daily build process include a run through JUnit test suites.

The developers at Borland recognize that both Ant and JUnit have made significant contributions to the development process. As a result, both tools are integrated into the JBuilder 7 IDE.

The JBuilder Ant and JUnit tools are mostly enterprise level development tools. However, you can and should use these tools with all editions of JBuilder. In particular, there are open source projects for integrating Ant into even the personal edition of JBuilder. The name of one tool for integrating Ant into JBuilder is AntRunner. You can find it here:

http://antrunner.sourceforge.net/

Once you have Ant integrated into JBuilder, then you can also integrate JUnit into your development process via Ant scripts. Or if you want, go to codecentral.borland.com and retrieve the unit testing tool. It should be available for download here:

http://codecentral.borland.com/codecentral/ccweb.exe/listing?id=17168

For a more in depth exploration of Ant and JUnit, please see the useful book called "Java Tools for Extreme Programming." Its emphasis on J2EE development is unfortunate, but it is nevertheless well written and contains plenty of useful information. It is published by the Wiley press and written by Hightower and Lesiecki.

Summary

In this article you have had a brief look at unit testing with the tool called JUnit. You have seen that this tool is well integrated into the JBuilder IDE. However, you can just as easily use JUnit from the command prompt.

Particularly if you are using the SE or personal version of JBuilder, you should visit www.junit.org. That site has many tips on using JUnit. Included on the site you will find tools that will help you automatically generate test cases using tools similar to those included with the enterprise version of JBuilder. You will also find some unique tools that can help you test the GUI portions of your applications.