JavaTest Harness Architect's Guide, JavaTest Harness 4.5 for the Java Platform E20663-03 |
|
Previous |
Next |
The JavaTest harness uses the TestSuite
object as a portal to information about the test suite; whenever the JavaTest harness requires information about the test suite, it queries the TestSuite
object. JavaTest reads the testsuite.jtt
file to determine the class name and class path for the test suite; JavaTest then uses those properties to instantiate the TestSuite
object. By default, the TestSuite
object also gets a number of other standard properties from the testsuite.jtt
file. As test suite architect, you create and maintain your TestSuite
class and the testsuite.jtt
file.
The testsuite.jtt
file is located in the top-level directory of the test suite and is a registry of information about the test suite that includes the paths to various JavaTest components as well as other static information about the test suite. The testsuite.jtt
file generally contains at least two entries that tell the JavaTest harness how to start the TestSuite
class:
A testsuite
entry that specifies the name of the TestSuite
class and any arguments the class requires
A classpath
entry that specifies the class path on which the main TestSuite
class can be found (typically, a JAR file that contains test suite-specific components). This entry is required if the TestSuite
class or any other classes the TestSuite
refers to are not located within javatest.jar
.
The testsuite.jtt
file usually contains other entries that specify information about the test suite; the JavaTest harness reads the file and passes the information to the TestSuite
class when it starts. Table 8-1, "testsuite.jtt Properties" describes the standard properties used by the TestSuite
and may be specified in the testsuite.jtt
file:
Table 8-1 testsuite.jtt Properties
Property | Description |
---|---|
An optional list of resource names that identify JavaHelp helpsets for documents to be added to the JavaTest Help menu. The content of the helpsets must be provided on the test suite classpath (see classpath above). Example: |
|
Extends the class path beyond Default: Nothing in addition to Example: |
|
A specialized entry to allow a legacy (prior to JavaTest version 3.0) test suite to override the values of |
|
The name of the test finder class and arguments (if any). This property is used by the default implementation of Example: The default implementation of
See the description of the testsuite.jtd entry below. |
|
A unique identifier composed of letters, digits, underscore, minus, and hyphen used to identify a specific version of a test suite. The JavaTest harness uses this property to ensure that component versions are compatible. By convention, the name is composed of the following parts: technologyNameTCK_version. Example: |
|
The path to the exclude list shipped with the test suite. If the path is relative, it is evaluated relative to test suite root directory. Always use " Example: |
|
The name of the interview class and arguments (if any). The default implementation of Example: |
|
The list of valid keywords for this test suite. If the entry is present and contains a list of keywords, the keywords are added to the configuration editor keywords combo box. If the entry is omitted, it is taken to mean "unspecified" — in which case the user can use the configuration editor to specify keywords, but the configuration editor keywords combo box is disabled. If the entry is present but empty, it is taken to mean "none" — in which case the configuration editor does not present the keyword questions and tabs to the user. |
|
Specifies the location (as a URL) where the latest exclude list can be obtained. The Example: |
|
Specifies the location on the class path of an image to be used as the test suite logo. The path is evaluated relative to the test suite root directory. This logo is displayed in the JavaTest Quick Start wizard. |
|
The name of the test suite. This property is a string of up to 80 characters. By convention the name is composed of the following parts: technology_name TCK version| Test Suite [(additional text)] Example: |
|
The name of the test script class and arguments (if any). This property is used by the default implementation of If this property is not specified, the default implementation of Example: |
|
serviceReader |
Enables service management for the test suite. See Chapter 13 for detailed information about the service management feature. |
The number of tests in the test suite. This property gives the JavaTest GUI a hint as to how many tests are in the test suite. Example: |
|
By default, the JavaTest harness looks for test source files and test descriptions in the Example: |
|
Optional class name for a custom Default: |
|
testsuite.jtd |
Can be used to override the default location of the BinaryTestFinder data file. By default the TestSuite class looks for a file named Example: |
tmcontext |
Optional class name for a custom Default: |
Note: The |
The following example shows the testsuite.jtt
file that is included with the tag example test suite.
# Test Suite properties file for DemoTCK test suite with # tag-style tests name=DemoTCK 1.0 Test Suite (Tag Tests) id=DemoTCK_tags_1.0 classpath=lib/jtdemotck.jar finder=com.sun.javatest.finder.TagTestFinder script=com.sun.javatest.lib.StdTestScript interview=com.sun.demotck.DemoTCKParameters
Although by default these properties are obtained from the testsuite.jtt
file, you can override this behavior in your TestSuite
class. By overriding the methods that get these properties, you can specify your own properties directly in the TestSuite
class and/or manipulate the properties from testsuite.jtt
as you wish. This is generally not necessary, but it is an option. Some reasons why you might choose to do this:
To hide or protect some of the properties
To determine some of these properties programmatically at runtime
To customize the TestSuite class, you must extend the base com.sun.javatest.TestSuite
class. For details about which methods you may choose to override, see the TestSuite
API documentation.