com.sun.javatest.\*: JT Harness API
By jjg on Nov 16, 2006
The JT Harness provides a bunch of API targeted at folk who want to design and build test suites. This is best described in the JavaTest Architect's Guide. But in addition, there's a bunch of API that you can use to write your own utilities, such as to process the results and store them in a database, or to generate your own specialized reports.
Most of the API that you'll want can be found in the
com.sun.javatest package. You can download the source code from the
JT Harness project and build the javadoc for full details of the API.
For example, you can open the work directory containing the results of a test run by calling
WorkDirectory.open(path). From a
WorkDirectory you can get a
TestResultTable, and from that you can get individual
TestResult objects that contain all the information available about how the test was run and what results were generated. You can iterate over all or part of the
TestResultTable to analyze the results for all or part of your test suite.
For the more adventurous, if you don't want to wait until the test run is over, you can monitor the results as they are being generated. The easiest way to do this is to specify an observer (i.e. a listener class) on the command line. Here's the relevant extract from the command line help:
-observer <option>... <classname> [<arg>...] [-end] Specify an observer to monitor the progress of a test run -cp <classpath> Specify additional locations in which to look for the observer class
The observer must implement the
com.sun.javatest.Harness.Observer interface, and will be notified when tests are starting and stopping. For more fine grain detail, the observer can register additional observers to monitor individual tests as they are being run. One common technique is to have an observer implement both
TestResult.Observer, and for the observer to register itself as an test result observer for selected tests when it is notified that a test is starting.
By the way, you might well ask why the JT Harness uses the "observer" terminology, instead of "listener". The answer is simply that we provided this functionality before the listener paradigm became as common as it is today.
If you want to go one step further, you can build and install your own command options for the command line. For example, you might wrap your observer in a command option, so that you can just use
-myMonitor on the command line to invoke it. Command line options are handled by the
com.sun.javatest.tool.CommandManager class, and so to provide a set of one or more command line options, you must provide your own
CommandManager. Command managers are loaded by a mechanism that is similar to the service loader mechanism that will be available in Java SE 6, although the details are currently slightly different. To make a command manager available, put your classes in a jar file, and put the name of your command manager class in a file called
JavaTest.cmdMgrs.lst in the root directory of your jar file. Run the harness with your jar file on the class path, and the harness will automatically make your new command option available for use.