The test suite runner project is the magic that makes everything come together and allows you to execute the test suite. If you fully understand how the JBoss Test Harness functions, and have a good grasp on Maven 2, then it's not to difficult to understand how the test suite runner project works. Regardless of your background, this guide covers what you need to know to get up and running by studying the test suite runner used to run the CDI TCK against the CDI RI, Weld.

The TCK runner for the Weld can be found in the jboss-tck-runner directory in the Weld distribution. The dependencies of the TCK runner project for Weld are listed in Table 12.1, “Weld JBoss TCK Runner Dependencies”.

You can find all of these artifacts in the JBoss Maven repository.

You should substituate the weld-core and weld-porting-package artifacts from table 2.2.3 with your own artifacts. You'll also need to replace the jboss-test-harness-jboss-as-51 artifact if you are not testing your implementation on JBoss AS 5.1. The jboss-test-harness-jboss-as-51 artifact contains implementations of the Containers SPI for the JBoss Test Harness for JBoss AS 5.1.

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-dependency-plugin</artifactId>
  <executions>
    <execution>
      <id>copy</id>
      <phase>process-resources</phase>
      <goals>
        <goal>copy</goal>
      </goals>
      <configuration>
        <stripVersion>true</stripVersion>
        <artifactItems>
          <artifactItem>
            <groupId>org.jboss.jsr299.tck</groupId>
            <artifactId>jsr299-tck-impl</artifactId>
            <type>xml</type>
            <classifier>suite</classifier>
            <overWrite>true</overWrite>
          </artifactItem>
          <artifactItem>
            <groupId>org.jboss.weld</groupId>
            <artifactId>
              weld-porting-package
            </artifactId>
            <overWrite>true</overWrite>
            <outputDirectory>
              ${project.build.directory}/dependency/lib
            </outputDirectory>
          </artifactItem>
          <artifactItem>
            <groupId>org.jboss.weld</groupId>
            <artifactId>weld-core-test</artifactId>
            <overWrite>true</overWrite>
            <outputDirectory>
              ${project.build.directory}/dependency/lib
            </outputDirectory>
          </artifactItem>
          <artifactItem>
            <groupId>javax.el</groupId>
            <artifactId>el-ri</artifactId>
            <overWrite>true</overWrite>
            <outputDirectory>
              ${project.build.directory}/dependency/lib
            </outputDirectory>
            </artifactItem>
          </artifactItems>
       </configuration>
     </execution>
   </executions>
</plugin>

The target folder for the copies of the dependencies (i.e., the JAR files) is declared as the JBoss Test Harness library directory; this results in these libraries being added to the test artifact using the following property assignment:

org.jboss.testharness.libraryDirectory=target/dependency/lib

We also copy the test suite configuration from the local Maven repository (groupId=org.jboss.jsr299.tck, artifactId=jsr299-tck-impl, classifier=suite, type=xml, version=1.0.0-SNAPSHOT) to a local repository as the TestNG Maven plugin expects a local file.

The TCK is executed using the Maven TestNG plugin. Maven 2 profiles are used to control the properties that are set at the time of the execution. For instance, the incontainer profile enables integration tests and disables standalone mode, changing the default settings.

The jboss-tck-runner project also defines the JBoss Test Harness extra configuration directory using the following property:

org.jboss.testharness.container.extraConfigurationDir=../jboss-as

The JBoss Test Harness looks in this directory for either a build.properties or local.build.properties file that declares additional configuration properties. In particular, the JBoss AS Containers implementation looks here to find the jboss.home property so it knows where the scripts are located to start and stop JBoss AS.

As you have learned, when the test suite is executing using in-container mode, each test class is packaged as a deployable artifact and deployed to the container. The test is then executed within the context of the deployed application. This leaves room for errors in packaging. When investigating a test failure, it's helpful to be able to inspect the artifact after it is generated. The JBoss Test Harness can accommodate this type of inspection by "dumping" the generated artifact to disk.

If you want to write the artifacts to disk, and avoid executing the test suite, you can simply execute the main method of the class org.jboss.testharness.api.TCK. For example you could use a Maven profile that is activated when the dumpArtifacts command line property is defined:

mvn test-compile -DdumpArtifacts

The output directory where the artifacts are written is defined by the property org.jboss.testharness.outputDirectory.

Once the artifact is written to disk, you have an option of manually deploying it to the container. You can execute the tests in the artfact by requesting the context path of the application in the browser. If you want to execute an individual test method, specify the method name in the methodName request parameter (e.g., ?methodName=testMethodName).