Setup and Configuration

Previous Next Contents

4 Setup and Configuration

Note

The Jakarta EE Specification process provides for any number of compatible implementations. As additional implementations become available, refer to project or product documentation from those vendors for specific TCK setup and operational guidance.

This chapter describes how to set up the RESTful Web Services TCK and JavaTest harness software. Before proceeding with the instructions in this chapter, be sure to install all required software, as described in Chapter 3, "Installation."

After completing the instructions in this chapter, proceed to Chapter 5, "Executing Tests," for instructions on running the RESTful Web Services TCK.

4.1 Configuring Your Environment to Run the TCK Against a Compatible Implementation

After configuring your environment as described in this section, continue with the instructions in Section 4.6, "Using the JavaTest Harness Software."

Note

In these instructions, variables in angle brackets need to be expanded for each platform. For example, <TS_HOME> becomes $TS_HOME on Solaris/Linux and %TS_HOME% on Windows. In addition, the forward slashes (/) used in all of the examples need to be replaced with backslashes (\) for Windows. Finally, be sure to use the appropriate separator for your operating system when specifying multiple path entries (; on Windows, : on UNIX/Linux).

On Windows, you must escape any backslashes with an extra backslash in path separators used in any of the following properties, or use forward slashes as a path separator instead.

  1. Set the following environment variables in your shell environment:

    1. JAVA_HOME to the directory in which Java SE 8 is installed

    2. TS_HOME to the directory in which the RESTful Web Services TCK 2.1 software is installed

    3. JAXRS_HOME to the directory in which the RESTful Web Services 2.1 CI has been installed

    4. PATH to include the following directories: JAVA_HOME/bin, JAXRS_HOME/bin, and <TS_HOME>/tools/ant/bin

  2. Edit your <TS_HOME>/bin/ts.jte file and set the following environment variables:

    1. Set the webServerHost property to the name of the host on which Jakarta EE 8 CII is running.
      The default setting is localhost.

    2. Set the webServerPort property to the port number of the host on which Jakarta EE 8 CI is running.
      The default setting is 8080.

    3. Set the web.home property to the installation directory of Jakarta EE 8 CI.

    4. Set the jaxrs.classes property to point to the classes or JAR file for the RESTful Web Services 2.1 API.
      The default setting for this property is ${web.home}/modules/javax.ws.rs-api.jar.

    5. Set the jaxrs_impl_lib and jaxrs_impl.classes properties to point to, for example the Eclipse Jersey 2.26 CI.
      The default setting for the jaxrs_impl_lib property is ${web.home}/modules/jersey-container-servlet-core.jar.
      The default setting, if you are using the Eclipse Jersey 2.26 CI for the `jaxrs_impl.`classes property is as follows (all on one line):

      ${web.home}/modules/jersey-client.jar:
      ${web.home}/modules/jersey-common.jar:
      ${web.home}/modules/jersey-server.jar:
      ${web.home}/modules/jersey-container-servlet.jar:
      ${web.home}/modules/jersey-container-servlet-core.jar:
      ${web.home}/modules/jersey-media-jaxb.jar:
      ${web.home}/modules/jersey-media-sse.jar:
      ${web.home}/modules/jersey-hk2.jar:
      ${web.home}/modules/osgi-resource-locator.jar:
      ${web.home}/modules/jakarta.inject.jar:
      ${web.home}/modules/guava.jar:
      ${web.home}/modules/hk2-api.jar:
      ${web.home}/modules/hk2-locator.jar:
      ${web.home}/modules/hk2-utils.jar:
      ${web.home}/modules/cglib.jar:
      ${web.home}/modules/asm-all-repackaged.jar:
      ${web.home}/modules/bean-validator.jar:
      ${web.home}/modules/endorsed/jakarta.annotation-api.jar
    6. Set the servlet_adaptor property to point to the Servlet adaptor class for the RESTful Web Services implementation.
      The default setting for this property, if you are using the Eclipse Jersey 2.26 CI is org/glassfish/jersey/servlet/ServletContainer.class.

    7. Set the impl.vi property to the name of the Jakarta EE 8 CI .
      The relevant porting files are located under the $TS_HOME/bin/xml/impl/glassfish/ directory.
      The default setting for this property, when using Eclipse GlassFish as the CI is glassfish.

    8. Set the jaxrs_impl_name property to the name of the RESTful Web Services CI.
      A file bearing this name has been created under <TS_HOME>/bin/xml/impl/glassfish/jersey.xml with packaging instructions.
      The default setting for this property when using the Eclipse Jersey 2.26 CI is jersey.

    9. Set the impl.vi.deploy.dir property to point to the autodeploy directory of the Jakarta EE 8 CI you are using.
      The default setting for this property is ${web.home}/domains/domain1/autodeploy.

    10. Verify that the tools.jar property is set to the location of the tools.jar file that is distributed with Java SE 8.

    11. Set the porting.ts.url.class.1 property to your porting implementation class that is used for obtaining URLs.
      The default setting for this property is com.sun.ts.lib.implementation.sun.common.SunRIURL.

    12. Optionally, to use your own implementation of HttpsURLConnection, set the porting.ts.HttpsURLConnection.class.1 property to your implementation of HttpsURLConnection.
      The default setting for this property is com.sun.ts.lib.implementation.sun.javaee.SunRIHttpsURLConnection.

    13. Set up users and passwords for your RESTful Web Services server.

      User Password Groups

      javajoe

      javajoe

      guest

      j2ee

      j2ee

      staff, mgr

      Also make sure the principal to role-mappings that are specified in the runtime XML files are properly mapped in your environment. These mappings may vary for each application.

  3. Provide your own implementation of the porting package interface provided with the RESTful Web Services TCK.
    The porting package interface, TSURLInterface.java, obtains URL strings for web resources in an implementation-specific manner. API documentation for the TSURLInterface.java porting package interface is available in the RESTful Web Services TCK documentation bundle.

  4. If the RESTful Web Services TCK test applications are published on a Servlet 2.5-compliant Web container to certify the VI, the servlet_adaptor property needs to be set in the ts.jte file, and VI-specific WAR files containing the Servlet information need to be created for publishing.
    The VI-specific WAR files should never override any existing files that come with the TCK. Refer to Appendix B, "Packaging the Test Applications in Servlet-Compliant WAR Files With VI-Specific Information," for more information.

  5. When creating VI-specific WAR files, deploying RESTful Web Services test applications, or running the RESTful Web Services TCK, it is recommended that you create a porting file named $jaxrs_impl_name under $TS_HOME/bin/xml/${impl_vi}.
    Use the jersey.xml file as a reference.

  6. Run the ant config.vi target to configure the Vendor Implementation that is defined in the impl.vi property.

    cd <TS_HOME>/bin
    ant config.vi

    This target performs the following tasks: * Stops the application server running the RESTful Web Services 2.1 CI * Copies the TCK-dependent files ${tslib.name}.jar and tsharness.jar into the application server’s external library folder * Starts the application server * Creates users and the appropriate roles * Enables HTTP trace requests

4.2 Configuring Your Environment to Repackage and Run the TCK Against the Vendor Implementation

After configuring your environment as described in this section, continue with the instructions in Section 4.4, "Using the JavaTest Harness Software."

Note

In these instructions, variables in angle brackets need to be expanded for each platform. For example, <TS_HOME> becomes $TS_HOME on Solaris/Linux and %TS_HOME% on Windows. In addition, the forward slashes (/) used in all of the examples need to be replaced with backslashes (\) for Windows. Finally, be sure to use the appropriate separator for your operating system when specifying multiple path entries (; on Windows, : on UNIX/Linux).

On Windows, you must escape any backslashes with an extra backslash in path separators used in any of the following properties, or use forward slashes as a path separator instead.

Before You Begin

Decide against which RESTful Web Services implementation the tests will be run and determine to which Servlet–compliant Web server the RESTful Web Services TCK applications will be published.

Package the RESTful Web Services test applications for that RESTful Web Services implementation and Servlet–compliant Web server.

See Appendix B, "Packaging the Test Applications in Servlet-Compliant WAR Files With VI-Specific Information," for information about repackaging the RESTful Web Services test application.

  1. Set the following environment variables in your shell environment:

    1. JAVA_HOME to the directory in which Java SE 8 is installed

    2. TS_HOME to the directory in which the RESTful Web Services TCK 2.1 software is installed

    3. JAXRS_HOME to the directory in which the RESTful Web Services 2.1 VI has been installed

    4. PATH to include the following directories: JAVA_HOME/bin, JAXRS_HOME/bin, and <TS_HOME>/tools/ant/bin

  2. Edit your <TS_HOME>/bin/ts.jte file and set the following environment variables:

    1. Set the webServerHost property to the name of the host on which your Web server is running that is configured with the Vendor Implementation.
      The default setting is localhost.

    2. Set the webServerPort property to the port number of the host on which the Web server is running that is configured with the Vendor RESTful Web Services 2.1 Vendor Implementation.
      The default setting is 8080.

    3. Set the web.home property to the installation directory of the Web server.

    4. Set the jaxrs.classes property to point to the classes or JAR file for the RESTful Web Services 2.1 API.
      The default setting for this property is ${web.home}/modules/javax.ws.rs-api.jar.

    5. If you are using Eclipse Jersey 2.26, set the jaxrs_impl_lib and jaxrs_impl.classes properties to point to the Eclipse Jersey 2.26 CI.
      The default setting for the jaxrs_impl_lib property is ${web.home}/modules/jersey-container-servlet-core.jar .
      The default setting for the `jaxrs_impl.`classes property is as follows (all on one line):

      ${web.home}/modules/jersey-client.jar:
      ${web.home}/modules/jersey-common.jar:
      ${web.home}/modules/jersey-server.jar:
      ${web.home}/modules/jersey-container-servlet.jar:
      ${web.home}/modules/jersey-container-servlet-core.jar:
      ${web.home}/modules/jersey-media-jaxb.jar:
      ${web.home}/modules/jersey-media-sse.jar:
      ${web.home}/modules/jersey-hk2.jar
      ${web.home}/modules/osgi-resource-locator.jar:
      ${web.home}/modules/jakarta.inject.jar:
      ${web.home}/modules/guava.jar:
      ${web.home}/modules/hk2-api.jar:
      ${web.home}/modules/hk2-locator.jar:
      ${web.home}/modules/hk2-utils.jar:
      ${web.home}/modules/cglib.jar:
      ${web.home}/modules/asm-all-repackaged.jar:
      ${web.home}/modules/bean-validator.jar:
      ${web.home}/modules/endorsed/jakarta.annotation-api.jar
    6. Set the servlet_adaptor property to point to the Servlet adaptor class for the RESTful Web Services implementation.
      The default setting for this property is org/glassfish/jersey/servlet/ServletContainer.class.

    7. Set the impl.vi property to the name of the Web server.
      The relevant porting files are located under the $TS_HOME/bin/xml/impl/${impl.vi}/ directory.
      The default setting for this property is glassfish.

    8. Set the jaxrs_impl_name property to the name of the RESTful Web Services implementation to be tested.
      The name of the property must be unique. A file bearing this name will be created under $TS_HOME/bin/xml/impl/${impl.vi}/${jaxrs_impl_name}.xml with packaging and/or deployment instructions.
      The default setting for this property is jersey.

    9. Set the impl.vi.deploy.dir property to point to the autodeploy directory for the Web server.
      The default setting for this property is ${web.home}/domains/domain1/autodpeloy.

    10. Verify that the tools.jar property is set to the location of the tools.jar file that is distributed with Java SE 8.

    11. Optionally, to use your own implementation of HttpsURLConnection, set the porting.ts.HttpsURLConnection.class.1 property to your implementation of HttpsURLConnection.
      The default setting for this property is com.sun.ts.lib.implementation.sun.javaee.SunRIHttpsURLConnection.

  3. Provide your own implementation of the porting package interface provided with the RESTful Web Services TCK.
    The porting package interface, TSURLInterface.java, obtains URL strings for web resources in an implementation-specific manner. API documentation for the TSURLInterface.java porting package interface is available in the RESTful Web Services TCK documentation bundle.

  4. If the RESTful Web Services TCK test applications are published on a Servlet 3.0-compliant Web container to certify the VI, the servlet_adaptor property needs to be set in the ts.jte file, and VI-specific WAR files containing the Servlet information need to be created for publishing.
    The VI-specific WAR files should never override any existing files that come with the TCK. Refer to Appendix B, "Packaging the Test Applications in Servlet-Compliant WAR Files With VI-Specific Information," for more information.

  5. When creating VI-specific application server settings, it is recommended that you create a configuring file named config.vi.xml under $TS_HOME/bin/xml/${impl_vi}.
    Use the $TS_HOME/bin/xml/glassfish/config.vi.xml file as a reference.

4.3 Publishing the Test Applications

The RESTful Web Services TCK provides an automatic way of deploying both the prebuilt and Vendor-built archives to the configured web container or containers by using deployment handlers.

The handler file (<TS_HOME>/bin/xml/impl/glassfish/jersey.xml is written to be used with Eclipse Jersey 2.26 and Jakarta EE 8 CI, Eclipse GlassFish 5.1. If the Vendor chooses not to use Jakarta EE 8 CI, Eclipse GlassFish 5.1 to run with their implementation but still chooses to publish to a Servlet-compliant Web container, then a VI-specific RESTful Web Services TCK tests Web archive needs to be created. This archive contains the VI-specific servlet class, and the Vendor should create their own version handler file to provide this functionality. It is recommended that the handler file be named ${jaxrs_impl_name} and be located in $TS_HOME/bin/xml/${impl.vi}/${jaxrs_impl_name}. Refer to Appendix B, "Packaging the Test Applications in Servlet-Compliant WAR Files With VI-Specific Information," for more information.

This section describes the various commands used for deploying the classes or WAR files to the configured web container.

4.3.1 Generic Deployment Command Scenarios

You can deploy all RESTful Web Services WAR files to Jakarta EE 8 CI or the Web server chosen by a Vendor, deploy just a single test directory, or deploy of subset of test directories.

4.3.1.1 To Deploy all the WAR Files From the <TS_HOME>/dist to a Web Server

Type the following command:

ant deploy.all

4.3.1.2 To Deploy a Single Test Directory

Type the following commands:

cd <TS_HOME>/src/com/sun/ts/tests/jaxrs/api/rs/get
ant deploy

4.3.1.3 To Deploy a Subset of Test Directories

Type the following commands:

cd <TS_HOME>/src/com/sun/ts/tests/jaxrs/api
ant deploy

4.3.2 Deploying the Prebuilt Archives

Note

If you are using a compatible implementation that is not Eclipse GlassFish 5.1, please refer to deployment details provided with that implementation.

This section explains issues regarding the deployment of the RESTful Web Services TCK prebuilt archives. Before conducting any deployment, ensure that your environment has been configured by following the instructions in either Section 4.1, "Configuring Your Environment to Run the TCK Against the Eclipse GlassFish 5.1 Compatible Implementation," or Section 4.2, "Configuring Your Environment to Repackage and Run the TCK Against the Vendor Implementation."

The <TS_HOME>/dist directory contains all WAR files for the RESTful Web Services TCK tests that have been compiled and packaged using the Eclipse GlassFish 5.1 Compatible Implementation for deployment on a Servlet-compliant Web container, Jakarta EE 8 CI, using the standard Web Archive (WAR) format.

These WAR files contain only Eclipse Jersey 2.26, a Jakarta EE 8 CI-specfic servlet adaptor, and are tailored to run against the Eclipse GlassFish 5.1 Compatible Implementation. These WAR files allow you to deploy (without any additional setup or modification) against the Eclipse GlassFish 5.1 Compatible Implementation to test the various features and functionality of this implementation.

To deploy the RESTful Web Services TCK tests, use either the deploy or deploy.all batch command as described in Section 4.3.1, "Generic Deployment Command Scenarios."

4.3.3 Deploying the Test Applications Against the Vendor Implementation

This section describes how to deploy the RESTful Web Services TCK test applications against the Vendor Implementation and vendor’s choice of Web server. Before conducting the deployment, ensure that you have followed the instructions in Section 4.2, "Configuring Your Environment to Repackage and Run the TCK Against the Vendor Implementation." Vendors can deploy RESTful Web Services TCK tests in either Java class or WAR format. All test resource classes are located under $TS_HOME/classes. All test resources packaged in WAR files are located under $TS_HOME/dist.

If a vendor chooses to deploy WAR files on a Servlet–compliant Web container other than a Jakarta EE 8 CI, it is necessary to build test WAR files that contain the VI’s servlet class and servlet class property in the web.xml deployment descriptor, as specified in the RESTful Web Services specification. The RESTful Web Services TCK comes with a web.xml.template file for each test, which contains all information except the servlet class. The RESTful Web Services TCK also comes with a tool to replace the CI or VI’s servlet adaptor class name in the web.xml.template. Refer to Appendix B, "Packaging the Test Applications in Servlet-Compliant WAR Files With VI-Specific Information," for more information about repackaging the RESTful Web Services TCK tests.

To deploy a resource class in class file format, a vendor must create a handler file that supports deploy options as described in Section 4.3.1, "Generic Deployment Command Scenarios." All tests with resource classes have a ${resource.classes} property set in each test’s individual build.xml file; this value contains all resource classes in the test.

To deploy the tests, the vendor should perform a deployment using either the deploy or deploy.all batch command, as described in Section 4.3.1, "Generic Deployment Command Scenarios."

4.4 Custom Configuration Handlers

Configuration handlers are used to configure and unconfigure a RESTful Web Services 2.1 implementation during the certification process. These are similar to deployment handlers but used for configuration. A configuration handler is an Ant build file that contains at least the required targets listed below:

  • config.vi - to configure the vendor implementation

  • clean.vi - to unconfigure the vendor implementation

These targets are called from the <TS_HOME>/bin/build.xml file and call down into the implementation-specific configuration handlers.

To provide your own configuration handler, create a config.vi.xml file with the necessary configuration steps for your implementation and place the file under the <TS_HOME>/bin/xml/impl/<your_impl> directory.

For more information, you may wish to view <TS_HOME>/bin/xml/impl/glassfish/config.vi.xml, the configuration file for Eclipse EE4J Jakarta EE 8 Compatible Implementation, Eclipse GlassFish.

4.5 Custom Deployment Handlers

Deployment handlers are used to deploy and undeploy the WAR files that contain the tests to be run during the certification process. A deployment handler is an Ant build file that contains at least the required targets listed in the table below.

The RESTful Web Services TCK provides these deployment handlers:

  • <TS_HOME>/bin/xml/impl/none/deploy.xml

  • <TS_HOME>/bin/xml/impl/glassfish/deploy.xml

  • <TS_HOME>/bin/xml/impl/tomcat/deploy.xml

The deploy.xml files in each of these directories are used to control deployment to a specific container (no deployment, deployment to the Eclipse GlassFish Web container, deployment to the Tomcat Web container) denoted by the name of the directory in which each deploy.xml file resides. The primary build.xml file in the <TS_HOME>/bin directory has a target to invoke any of the required targets (-deploy, -undeploy, -deploy.all, -undeploy.all).

4.5.1 To Create a Custom Deployment Handler

To deploy tests to another RESTful Web Services implementation, you must create a custom handler.

  1. Create a new directory in the <TS_HOME>/bin/xml/impl directory tree. For example, create the <TS_HOME>/bin/xml/impl/my_deployment_handler directory. Replace my_deployment_handler with the value of the impl.vi property that you set in Step 5 of the configuration procedure described in Section 4.2, "Configuring Your Environment to Repackage and Run the TCK Against the Vendor Implementation".

  2. Copy the deploy.xml file from the <TS_HOME>/bin/xml/impl/none directory to the directory that you created.

  3. Modify the required targets in the deploy.xml file. This is what the deploy.xml file for the "none" deployment handler looks like.

    <project name="No-op Deployment" default="deploy">
        <!-- No-op deployment target -->
        <target name="-deploy">
            <echo message="No deploy target implemented for this deliverable"/>
        </target>
        <target name="-undeploy">
            <echo message="No undeploy target implemented for this deliverable"/>
        </target>
        <target name="-deploy.all">
            <echo message="No deploy target implemented for this deliverable"/>
        </target>
        <target name="-undeploy.all">
            <echo message="No undeploy target implemented for this deliverable"/>
        </target>
    </project>

    Although this example just echoes messages, it does include the four required Ant targets (-deploy, -undeploy, -deploy.all, -undeploy.all) that your custom deploy.xml file must contain. With this as your starting point, look at the required targets in the deploy.xml files in the Tomcat and Eclipse Glassfish directories for guidance as you create the same targets for the Web container in which you will run your implementation of RESTful Web Services.

The following Ant targets can be called from anywhere under the <TS_HOME>/src directory:

  • deploy

  • undeploy

  • deploy.all

  • undeploy.all

The deploy.all and undeploy.all targets can also be called from the <TS_HOME>/bin directory.

Note

The targets in the deploy.xml file are never called directly. They are called indirectly by the targets listed above.

4.6 Using the JavaTest Harness Software

There are two general ways to run the RESTful Web Services TCK test suite using the JavaTest harness software:

4.7 Using the JavaTest Harness Configuration GUI

You can use the JavaTest harness GUI to modify general test settings and to quickly get started with the default RESTful Web Services TCK test environment. This section covers the following topics:

Note

It is only necessary to proceed with this section if you want to run the JavaTest harness in GUI mode. If you plan to run the JavaTest harness in command-line mode, skip the remainder of this chapter, and continue with Chapter 5, "Executing Tests."

4.7.1 Configuration GUI Overview

In order for the JavaTest harness to execute the test suite, it requires information about how your computing environment is configured. The JavaTest harness requires two types of configuration information:

  • Test environment: This is data used by the tests. For example, the path to the Java runtime, how to start the product being tested, network resources, and other information required by the tests in order to run. This information does not change frequently and usually stays constant from test run to test run.

  • Test parameters: This is information used by the JavaTest harness to run the tests. Test parameters are values used by the JavaTest harness that determine which tests in the test suite are run, how the tests should be run, and where the test reports are stored. This information often changes from test run to test run.

The first time you run the JavaTest harness software, you are asked to specify the test suite and work directory that you want to use. (These parameters can be changed later from within the JavaTest harness GUI.)

Once the JavaTest harness GUI is displayed, whenever you choose Start, then Run Tests to begin a test run, the JavaTest harness determines whether all of the required configuration information has been supplied:

  • If the test environment and parameters have been completely configured, the test run starts immediately.

  • If any required configuration information is missing, the configuration editor displays a series of questions asking you the necessary information. This is called the configuration interview. When you have entered the configuration data, you are asked if you wish to proceed with running the test.

4.7.2 Starting the Configuration GUI

Before you start the JavaTest harness software, you must have a valid test suite and Java SE 8 installed on your system.

The RESTful Web Services TCK includes an Ant script that is used to execute the JavaTest harness from the <TS_HOME> directory. Using this Ant script to start the JavaTest harness is part of the procedure described in Section 4.7.3, "To Configure the JavaTest Harness to Run the TCK Tests."

When you execute the JavaTest harness software for the first time, the JavaTest harness displays a Welcome dialog box that guides you through the initial startup configuration.

  • If it is able to open a test suite, the JavaTest harness displays a Welcome to JavaTest dialog box that guides you through the process of either opening an existing work directory or creating a new work directory as described in the JavaTest online help.

  • If the JavaTest harness is unable to open a test suite, it displays a Welcome to JavaTest dialog box that guides you through the process of opening both a test suite and a work directory as described in the JavaTest documentation.

After you specify a work directory, you can use the Test Manager to configure and run tests as described in Section 4.7.3, "To Configure the JavaTest Harness to Run the TCK Tests."

4.7.3 To Configure the JavaTest Harness to Run the TCK Tests

The answers you give to some of the configuration interview questions are specific to your site. For example, the name of the host on which the JavaTest harness is running. Other configuration parameters can be set however you wish. For example, where you want test report files to be stored.

Note that you only need to complete all these steps the first time you start the JavaTest test harness. After you complete these steps, you can either run all of the tests by completing the steps in Section 5.1, "Starting JavaTest," or run a subset of the tests by completing the steps in Section 5.2, "Running a Subset of the Tests."

  1. Change to the <TS_HOME>/bin directory and start the JavaTest test harness:
    cd <TS_HOME>/bin
    ant gui

  2. From the File menu, click Open Quick Start Wizard.
    The Welcome screen displays.

  3. Select Start a new test run, and then click Next.
    You are prompted to create a new configuration or use a configuration template.

  4. Select Create a new configuration, and then click Next.
    You are prompted to select a test suite.

  5. Accept the default suite (<TS_HOME>/src), and then click Next.
    You are prompted to specify a work directory to use to store your test results.

  6. Type a work directory name or use the Browse button to select a work directory, and then click Next.
    You are prompted to start the configuration editor or start a test run. At this point, the RESTful Web Services TCK is configured to run the default test suite.

  7. Deselect the Start the configuration editor option, and then click Finish.

  8. Click Run Tests, then click Start.
    The JavaTest harness starts running the tests.

  9. To reconfigure the JavaTest test harness, do one of the following:

    • Click Configuration, then click New Configuration.

    • Click Configuration, then click Change Configuration.

  10. Click Report, and then click Create Report.

  11. Specify the directory in which the JavaTest test harness will write the report, and then click OK.
    A report is created, and you are asked whether you want to view it.

  12. Click Yes to view the report.

4.7.4 Modifying the Default Test Configuration

The JavaTest GUI enables you to configure numerous test options. These options are divided into two general dialog box groups:

  • Group 1: Available from the JavaTest Configure/Change Configuration submenus, the following options are displayed in a tabbed dialog box:

    • Tests to Run

    • Exclude List

    • Keywords

    • Prior Status

    • Test Environment

    • Concurrency

    • Timeout Factor

  • Group 2: Available from the JavaTest Configure/Change Configuration/Other Values submenu, or by pressing Ctrl+E, the following options are displayed in a paged dialog box:

    • Environment Files

    • Test Environment

    • Specify Tests to Run

    • Specify an Exclude List

Note that there is some overlap between the functions in these two dialog boxes; for those functions use the dialog box that is most convenient for you. Please refer to the JavaTest Harness documentation or the online help for complete information about these various options.


Previous Next Contents
Eclipse Foundation Logo  Copyright © 2018, Oracle and/or its affiliates. All rights reserved.