1:28 p.m.
Author: pete.muir(a)jboss.org
Date: 2009-07-24 14:28:01 -0400 (Fri, 24 Jul 2009)
New Revision: 3201
Modified:
tck/trunk/doc/reference/en-US/executing.xml
Log:
ws
Modified: tck/trunk/doc/reference/en-US/executing.xml
===================================================================
--- tck/trunk/doc/reference/en-US/executing.xml 2009-07-24 18:18:19 UTC (rev 3200)
+++ tck/trunk/doc/reference/en-US/executing.xml 2009-07-24 18:28:01 UTC (rev 3201)
@@ -1,196 +1,210 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]>
<chapter id="executing">
- <title>Executing the Test Suite</title>
- <para>This chapter explains how to run the TCK on the JSR-299 RI as well as your
own implementation. The JSR-299 TCK uses the Maven 2 TestNG plugin and the JBoss Test
Harness to execute the test suite. Learning to execute the test suite from Maven 2 is
prerequisite knowlege for running the tests in an IDE, such as Eclipse.</para>
- <section>
- <title>The Test Suite Runner</title>
- <para>Each test class is treated as an individual artifact (hence the
<literal>@Artifact</literal> annotation on the class). All test methods (i.e.,
methods annotated with <literal>@Test</literal>) in the test class are run in
the same JSR-299 root context, meaning bean discovery occurs exactly once per artifact and
the same BeanManager is used by each test method in the class.</para>
- <para>The test suite is executed by the Maven 2 TestNG plugin during the test
phase of the Maven 2 life cycle. The execution happens within a TCK runner project (as
opposed to the TCK project itself). Web Beans includes a TCK runner project that executes
the JSR-299 TCK on the JSR-299 RI (Web Beans) running inside JBoss AS 5.1. To execute the
JSR-299 TCK on your own JSR-299 implementation, you must modify the TCK runner project
included with Web Beans to use your JSR-299 implementation as described in section
4.2.</para>
- </section>
- <section>
- <title>Running the Tests In Standalone Mode</title>
- <para>To execute the TCK test suite against the JSR-299 RI, first switch to the
jboss-tck-runner directory in the extracted Web Beans distribution:</para>
- <programlisting>cd
<webbeans_install_dir>/jboss-tck-runner</programlisting>
- <para>Then execute the Maven 2 life cycle through the test phase:</para>
- <programlisting>mvn test</programlisting>
- <para>Without any command-line flags, the test suite is run in standalone mode,
which means that any test class with the
<literal>(a)org.jboss.testharness.impl.packaging.IntegrationTest</literal>
annotation is skipped. This mode uses the
<literal>StandaloneContainers</literal> SPI to invoke the test artifact within
a mock Java EE life cycle and capture the results of the test. However, passing the suite
in this mode is not sufficient to pass the TCK as a whole. The suite must be passed while
executing in in-container mode.</para>
- </section>
- <section>
- <title>Running the Tests In the Container</title>
- <para>To execute the test suite using in-container mode with the JBoss TCK
runner, you first have to set the property <literal>jboss.home</literal> to
the location of a JBoss AS 5.1 installation. This property is set in the following Java
properties file within the extracted Web Beans distribution:</para>
-
<programlisting><webbeans_install_dir>/jboss-as/local.build.properties</programlisting>
- <para>Then, add the <literal>incontainer</literal> property to the
command that launches the Maven 2 life cycle:</para>
- <programlisting>mvn test -Dincontainer</programlisting>
- <para>The presence of the <literal>incontainer</literal> property
activates a Maven 2 profile that assigns the
<literal>org.jboss.testharness.standalone</literal> system property to
<literal>false</literal> and the
<literal>org.jboss.testharness.runIntegrationTests</literal> system property
to <literal>true</literal>, hence activing the in-container test mode. This
time, all the test artifacts in the test suite are executed.</para>
- <para>The in-container profile will also start and stop the application server
automatically by setting the
<literal>org.jboss.testharness.container.forceRestart</literal> to
<literal>true</literal>. If you want to connect to an instance that is already
running, activate in-container mode using the
<literal>incontainer-debug</literal> command line property
instead.</para>
- <programlisting>mvn test -Dincontainer-debug</programlisting>
- <para>The in-container mode uses the <literal>Containers</literal>
SPI to deploy the test artifact to the container and execute the test in a true Java EE
life cycle. The JBoss TCK runner has a dependency on the library that provides an
implementation of this interface for JBoss AS 5.1.</para>
- <para>Since in-container tests are executed in a remote JVM, the results of the
test must be communicated back to the runner over a container-supported protocol. The
JBoss Test Harness provides servlet-based communication over HTTP as described in section
3.3.</para>
- </section>
- <section>
- <title>Running a Subset of Tests</title>
- <para>The TCK test suite is controlled by a TestNG descriptor. The TestNG
descriptor tck-tests.xml, located in the src/main/resources directory of the
jsr299-tck-impl project, defines the TCK test suite. The main configuration in this file
is the packages filter, shown below, which instructs TestNG to look in the
<literal>org.jboss.jsr299.tck.tests</literal> package to find the test
classes.</para>
- <programlisting><packages>
- <package name="org.jboss.jsr299.tck.tests"/>
-</packages></programlisting>
- <para>The descriptor also includes configuration of a method selector
implementation, shown below, that allows integration tests to be skipped when the test
suite is executed in standalone mode.</para>
- <programlisting><method-selectors>
- <method-selector>
- <selector-class name="org.jboss.testharness.impl.
-testng.DisableIntegrationTestsMethodSelector" />
- </method-selector>
-</method-selectors></programlisting>
- <para>You may also notice other filters in this class, which are used to
disable broken tests while the JSR-299 RI and the TCK are being developed. When both are
final, you can expect these filters to be removed. However, you may want to use similar
filters to disable tests while you are working on an implementation. Alternatively, you
can explicity list the classes that you want to have executed if you are focusing on a
specific area of the TCK. See the <ulink
url="http://testng.org/doc/documentation-main.html">TestNG reference
guide</ulink> for more information about how you can control which classes are
selected to be run when the test suite is executed.</para>
- </section>
- <section>
- <title>Dumping the Test Artifacts</title>
- <para>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 investingating a test failure, it's helpful to be
able to inspect the artifact after it is generated. The TCK can accomodate this type of
inspection by "dumping" the generated artifact to disk.</para>
- <para>If the <literal>dumpArtifacts</literal> is defined as a
system property or defined in the classpath resource
META-INF/jboss-test-harness.properties and has a value of
<literal>true</literal>, the JBoss Test Harness will write the artifact to an
output directory prior to deploying it to the server. This behavior is activated in the
jboss-tck-runner project by appending the <literal>dumpArtifacts</literal>
command line property to the end of the command that invokes the Maven test
phase.</para>
- <programlisting>mvn test -Dincontainer -DdumpArtifacts</programlisting>
- <para>If you only want to write the artifacts to disk, and avoid executing the
test suite, you can simply execute the main method of the class
<literal>org.jboss.testharness.api.TCK</literal>. This execution is configured
as a Maven profile that is activated when the <literal>dumpArtifacts</literal>
command line property is defined:</para>
- <programlisting>mvn test-compile -DdumpArtifacts</programlisting>
- <para>The output directory where the artifacts are written is defined by the
property <literal>org.jboss.testharness.outputDirectory</literal>. The
jboss-tck-runner project is configured to dump the artifacts to the
target/jsr299-artifacts directory.</para>
- <para>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 <literal>methodName</literal> request
parameter (e.g., ?methodName=testMethodName).</para>
- </section>
- <section>
- <title>Running a Test in Eclipse</title>
- <para>The primary motivation for building the test harness on top of an
existing testing framework is to allow the tests to be executed and debugged in an
Integrated Development Environment (IDE) using availalbe plugins. It's also the
easiest way to execute a test class in isolation.</para>
- <para>The TCK can be executed in any IDE for which there is a TestNG plugin
available. Running a test in Eclipse is almost as simple as running the test with the
Eclipse TestNG plugin. You can also use the TestNG plugin to debug a test, which is
described in the next chapter.</para>
- <para>Before running a test from the TCK test suite in Eclipse, you must have
the Eclipse <ulink url="http://testng.org">TestNG plugin</ulink>
installed. Instructions for using the TestNG update site to add the TestNG plugin to
Eclipse are provided on the TestNG <ulink
url="http://testng.org/doc/download.html">download page</ulink>. You
can find a tutorial that explains how to use the TestNG plugin on the TestNG <ulink
url="http://testng.org/doc/eclipse.html">Eclipse
page</ulink>.</para>
- <para>You should also have the <ulink
url="http://m2eclipse.codehaus.org">m2eclipse plugin</ulink> installed.
This plugin absolutely essential for working with Maven 2 projects, which both the JSR-299
RI and the TCK are. Instructions for using the m2eclipse update site to add the m2eclipse
plugin to Eclipse are provided on the m2eclipse home page. Sonatype, the company that
maintains the m2eclipse plugin and is a strong supporter of Maven, publishes an entire
<ulink
url="http://www.sonatype.com/books/m2eclipse-book/reference">...
guide</ulink> dedicated to the plugin on their website.</para>
- <para>Once you have the m2eclipse plugin installed, import the JSR-299 TCK
projects. You should also import the JSR-299 RI projects if you want to debug into that
code.</para>
- <para>When setting up your Ecilpse workspace, I recommend creating three
workings sets: one for the JSR-299 RI (Web Beans), one for the JSR-299 TCK and one for the
JBoss TCK Runner. The dependencies between the projects will be established automatically
by the m2eclipse plugin based on the dependency information in the pom.xml files. Your
workspace should appear as follows:</para>
- <programlisting>JSR-299 RI
- jsr299-api
- webbeans-api
- webbeans-core
- webbeans-core-test
- webbeans-logging
- webbeans-parent
- webbeans-spi
- webbeans-version-matrix
-JSR-299 TCK
- jsr299-tck-api
- jsr299-tck-impl
- parent
-Web Beans JBoss TCK Runner
- webbeans-jboss-tck-runner
- webbeans-porting-package</programlisting>
- <para>The tests in the TCK test suite are located in the jsr299-tck-impl
project. You'll be working within this project in Eclipse when you are developing
tests. However, you learned earlier, there are no references to a JSR-299 implementation
in the TCK. So how can you execute an individual test in Eclipse? The secret is that you
need to establish a link in Eclipse (not in Maven) between the jsr299-tck-impl project and
your TCK runner project, which in this case is webbeans-jboss-tck-runner. Here are the
steps to establish the link:</para>
- <orderedlist>
- <listitem>
- <para>Right click on the jsr299-tck-impl project</para>
- </listitem>
- <listitem>
- <para>Select Build Path > Configure Build Path...</para>
- </listitem>
- <listitem>
- <para>Click on the Projects tab</para>
- </listitem>
- <listitem>
- <para>Click the Add... button on the right</para>
- </listitem>
- <listitem>
- <para>Check the TCK runner project (e.g.,
webbeans-jboss-tck-runner)</para>
- </listitem>
- <listitem>
- <para>Click the OK button on the Required Project Selection dialog
window</para>
- </listitem>
- <listitem>
- <para>Click the OK button on the Java Build Path window</para>
- </listitem>
- </orderedlist>
- <para>The TCK runner project should pull in the JSR-299 implementation, the TCK
porting package and any additional properties that must be defined to execute the TCK test
suite.</para>
- <para>Your now ready to execute an individual test class (a class which extends
AbstractJSR299Test and is annotated with @Artifact). Select a test class that is
<emphasis role="italic">not</emphasis> annotated with
<literal>@IntegrationTest</literal> and open it in the Eclipse editor. Right
click in the editor view and select TestNG > Run as test. The TestNG view should
pop out and you should see all the tests pass (hopefully).</para>
- <note>
- <para>If the TCK complains that there is a property missing, close all the
projects, open them again, and rebuild. The m2eclipse plugin can be finicky getting
everything built correctly the first time.</para>
- </note>
- <para>So far you have executed a test in standalone mode. That's not
sufficient to pass the TCK. The test must be executed in in-container mode. Using
in-container mode also the only way to execute a test annotated with
<literal>@IntegrationTest</literal> as it requires container resources. So
let's see what has to be done to execute an integration test. This will result in
the artifact being deployed to the container, which is JBoss AS 5.1 if you are using the
JBoss TCK runner.</para>
- <para>As you have learned, the JBoss test harness determines how to behave
based on the values of numerous system properties or properties defined in
META-INF/jboss-test-harness.properties classpath resources. If the property named
<literal>org.jboss.testharness.standalone</literal> is not defined, the
harness assumes that the test is to be run in standalone mode. In order to run the tests
in the container, you need to add a properties file to the classpath that sets the
standalone property to false and provides values for other properties required to run an
in-container test.</para>
- <para>The JBoss TCK runner project conveniently provides the properties file
src/test/debug-resources/META-INF/jboss-test-harness.properties that contains all of the
necessary properties. You may have to tune the
<literal>org.jboss.testharness.container.extraConfigurationDir</literal> and
<literal>org.jboss.testharness.libraryDirectory</literal> properties to point
to the relative location of the related projects. The properties should be defined as
follows:</para>
- <itemizedlist>
- <listitem>
-
<para><literal>org.jboss.testharness.container.extraConfigurationDir</literal>
- the relative path from the jboss-tck-impl project to a directory that contains a
build.properties or local.build.properties file defining the location of a JBoss AS 5.1
installation in the <literal>jboss.home</literal> property</para>
- </listitem>
- <listitem>
- <para><literal>org.jboss.testharness.libraryDirectory</literal>
- the relative path from the jboss-tck-impl project to the target/dependency/lib directory
in the TCK runner project.</para>
- </listitem>
- </itemizedlist>
- <para>The other properties in that file are defined as follows:</para>
- <programlisting>org.jboss.testharness.standalone=false
-org.oss.testharness.container.forceRestart=false
-org.oss.testharness.runIntegrationTests=true</programlisting>
- <para>You're now ready to execute an integration test. Select an
integration test (a class that extends <literal>AbstractJSR299Test</literal>
and is annotated with both <literal>@Artifact</literal> and
<literal>@IntegrationTest</literal>) and open it in your Eclipse editor.
Follow these steps to execute the class with the TestNG plugin:</para>
- <orderedlist>
- <listitem>
- <para>Right click in the editor view and select TestNG > Run as
test</para>
- </listitem>
- <listitem>
- <para>Observe the test fail because of missing dependencies</para>
- </listitem>
- <listitem>
- <para>Select the Run > Run Configurations... menu from the main
menubar</para>
- </listitem>
- <listitem>
- <para>Select the name of the test class under the TestNG
category</para>
- </listitem>
- <listitem>
- <para>Select the Classpath tab</para>
- </listitem>
- <listitem>
- <para>Select User Entries in the tree</para>
- </listitem>
- <listitem>
- <para>Click the Advanced... button on the right</para>
- </listitem>
- <listitem>
- <para>Select Add Folders and click the OK button</para>
- </listitem>
- <listitem>
- <para>Select the webbeans-jboss-tck-runner/src/test/debug-resources
folder</para>
- </listitem>
- <listitem>
- <para>Click the OK button on the Folder Selection dialog
window</para>
- </listitem>
- <listitem>
- <para>Click on the webbeans-jboss-tck-runner entry</para>
- </listitem>
- <listitem>
- <para>Move the webbeans-jboss-tck-runner to the first entry using the Up
button</para>
- </listitem>
- <listitem>
- <para>Click the Run button on the Run Configurations dialog
window</para>
- </listitem>
- </orderedlist>
- <para>When you run the test this time, it should pass. If you get a failure
that the container (e.g., JBoss AS 5.1) must be run with assertions enabled, you need to
stop the container and start it with the -ea flag (or just leave it stopped and the test
will start it appropriately). </para>
- <para>You can simply right click and select TestNG > Run as test for all
subsequent runs for the reason cited earlier, the run configuration for a class is
retained indefinitely.</para>
- <para>Alternatively, you can configure TestNG to execute all tests in-container
by default by adding the properties file in the debug-resources folder to the
project's classpath as follows:</para>
- <orderedlist>
- <listitem>
- <para>Right click on the jsr299-tck-impl project</para>
- </listitem>
- <listitem>
- <para>Select Build Path > Configure Build Path...</para>
- </listitem>
- <listitem>
- <para>Click on the Libraries tab</para>
- </listitem>
- <listitem>
- <para>Click the Add Class Folder... button on the right</para>
- </listitem>
- <listitem>
- <para>Check the webbeans-jboss-tck-runner/src/test/debug-resources
folder</para>
- </listitem>
- <listitem>
- <para>Click the OK button on the Class Folder Selection dialog
window</para>
- </listitem>
- <listitem>
- <para>Click the OK button on the Java Build Path window</para>
- </listitem>
- </orderedlist>
- <para>Now you don't have to do any special configuration for each test
class.</para>
- <para>You can stop the individual tests from running in-container by reversing
the steps above to remove the debug-resources folder from the Eclipse classpath.
</para>
- <para>You have now mastered running the JSR-299 TCK against the JSR-299 RI
using both Maven 2 and within Eclipse. Now you're likely interested in how to
debug a test so that you can efficiently investigate test failures.</para>
- </section>
+ <title>Executing the Test Suite</title>
+ <para>
+ This chapter explains how to run the TCK on the JSR-299 RI as well as
+ your own implementation. The JSR-299 TCK uses the Maven 2 TestNG plugin
+ and the JBoss Test Harness to execute the test suite. Learning to execute
+ the test suite from Maven 2 is prerequisite knowlege for running the tests
+ in an IDE, such as Eclipse.
+ </para>
+ <section>
+ <title>The Test Suite Runner</title>
+ <para>
+ Each test class is treated as an individual artifact (hence the
+ <literal>@Artifact</literal>
+ annotation on the class). All test methods (i.e., methods annotated
+ with
+ <literal>@Test</literal>
+ ) in the test class are run in the same JSR-299 root context, meaning
+ bean discovery occurs exactly once per artifact and the same
+ BeanManager is used by each test method in the class.
+ </para>
+ <para>
+ The test suite is executed by the Maven 2 TestNG plugin during the test
+ phase of the Maven 2 life cycle. The execution happens within a TCK
+ runner project (as opposed to the TCK project itself). Web Beans
+ includes a TCK runner project that executes the JSR-299 TCK on the
+ JSR-299 RI (Web Beans) running inside JBoss AS 5.1. To execute the
+ JSR-299 TCK on your own JSR-299 implementation, you must modify the TCK
+ runner project included with Web Beans to use your JSR-299
+ implementation as described in
+ <xref linkend="tck-harness-properties" />
+ </para>
+ </section>
+
+ <section>
+ <title>Running the Tests In Standalone Mode</title>
+ <para>
+ To execute the TCK test suite against the JSR-299 RI, first switch
+ to the jboss-tck-runner directory in the extracted Web Beans
+ distribution:
+ </para>
+
+ <programlisting>cd webbeans/jboss-tck-runner</programlisting>
+ <para>
+ Then execute the Maven 2 life cycle through the test phase:
+ </para>
+ <programlisting>mvn test</programlisting>
+ <para>
+ Without any command-line flags, the test suite is run in standalone
+ mode, which means that any test class with the
+ <literal>(a)org.jboss.testharness.impl.packaging.IntegrationTest
+ </literal>
+ annotation is skipped. This mode uses the
+ <literal>StandaloneContainers</literal>
+ SPI to invoke the test artifact within a mock Java EE life cycle and
+ capture the results of the test. However, passing the suite in this
+ mode is not sufficient to pass the TCK as a whole. The suite must be
+ passed while executing in in-container mode.
+ </para>
+ </section>
+ <section>
+ <title>Running the Tests In the Container</title>
+ <para>
+ To execute the test suite using in-container mode with the JBoss TCK
+ runner, you first have to set the property
+ <literal>jboss.home</literal>
+ to the location of a JBoss AS 5.1 installation. This property is set in
+ the following Java properties file within the extracted Web Beans
+ distribution:
+ </para>
+
<programlisting>webbeans_install_dir/jboss-as/local.build.properties</programlisting>
+ <para>
+ Then, add the
+ <literal>incontainer</literal>
+ property to the command that launches the Maven 2 life cycle:
+ </para>
+ <programlisting>mvn test -Dincontainer</programlisting>
+ <para>
+ The presence of the
+ <literal>incontainer</literal>
+ property activates a Maven 2 profile that assigns the
+ <literal>org.jboss.testharness.standalone</literal>
+ system property to
+ <literal>false</literal>
+ and the
+ <literal>org.jboss.testharness.runIntegrationTests</literal>
+ system property to
+ <literal>true</literal>
+ , hence activating the in-container test mode. This time, all the test
+ artifacts in the test suite are executed.
+ </para>
+ <para>
+ The in-container profile will also start and stop the application
+ server automatically by setting the
+ <literal>org.jboss.testharness.container.forceRestart</literal>
+ to
+ <literal>true</literal>
+ . If you want to connect to an instance that is already running,
+ activate in-container mode using the
+ <literal>incontainer-debug</literal>
+ command line property instead.
+ </para>
+ <programlisting>mvn test -Dincontainer-debug</programlisting>
+ <para>
+ The in-container mode uses the
+ <literal>Containers</literal>
+ SPI to deploy the test artifact to the container and execute the test
+ in a true Java EE life cycle. The JBoss TCK runner has a dependency on
+ the library that provides an implementation of this interface for JBoss
+ AS 5.1.
+ </para>
+ <para>
+ Since in-container tests are executed in a remote JVM, the results
+ of the test must be communicated back to the runner over a
+ container-supported protocol. The JBoss Test Harness provides
+ servlet-based communication over HTTP as described in section 3.3.
+ </para>
+ </section>
+ <section>
+ <title>Running a Subset of Tests</title>
+ <para>
+ The TCK test suite is controlled by a TestNG descriptor. The TestNG
+ descriptor tck-tests.xml, located in the src/main/resources directory
+ of the jsr299-tck-impl project, defines the TCK test suite. The main
+ configuration in this file is the packages filter, shown below, which
+ instructs TestNG to look in the
+ <literal>org.jboss.jsr299.tck.tests</literal>
+ package to find the test classes.
+ </para>
+ <programlisting><![CDATA[<packages>
+ <package name="org.jboss.jsr299.tck.tests"/>
+</packages>]]></programlisting>
+ <para>
+ The descriptor also includes configuration of a method selector
+ implementation, shown below, that allows integration tests to be
+ skipped when the test suite is executed in standalone mode.
+ </para>
+ <programlisting><![CDATA[<method-selectors>
+ <method-selector>
+ <selector-class
name="org.jboss.testharness.impl.testng.DisableIntegrationTestsMethodSelector"
/>
+ </method-selector>
+</method-selectors>]]></programlisting>
+ <para>
+ You may also notice other filters in this class, which are used to
+ disable broken tests while the JSR-299 RI and the TCK are being
+ developed. When both are final, you can expect these filters to be
+ removed. However, you may want to use similar filters to disable tests
+ while you are working on an implementation. Alternatively, you can
+ explicity list the classes that you want to have executed if you are
+ focusing on a specific area of the TCK. See the
+ <ulink
url="http://testng.org/doc/documentation-main.html">TestNG reference
guide</ulink>
+ for more information about how you can control which classes are
+ selected to be run when the test suite is executed.
+ </para>
+ </section>
+ <section>
+ <title>Dumping the Test Artifacts</title>
+ <para>
+ 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 investingating a test failure, it's helpful to be able
+ to inspect the artifact after it is generated. The TCK can accomodate
+ this type of inspection by "dumping" the generated artifact to disk.
+ </para>
+ <para>
+ If the
+ <literal>dumpArtifacts</literal>
+ is defined as a system property or defined in the classpath resource
+ META-INF/jboss-test-harness.properties and has a value of
+ <literal>true</literal>
+ , the JBoss Test Harness will write the artifact to an output directory
+ prior to deploying it to the server. This behavior is activated in the
+ jboss-tck-runner project by appending the
+ <literal>dumpArtifacts</literal>
+ command line property to the end of the command that invokes the Maven
+ test phase.
+ </para>
+ <programlisting>mvn test -Dincontainer
-DdumpArtifacts</programlisting>
+ <para>
+ If you only want to write the artifacts to disk, and avoid executing
+ the test suite, you can simply execute the main method of the class
+ <literal>org.jboss.testharness.api.TCK</literal>
+ . This execution is configured as a Maven profile that is activated
+ when the
+ <literal>dumpArtifacts</literal>
+ command line property is defined:
+ </para>
+ <programlisting>mvn test-compile -DdumpArtifacts</programlisting>
+ <para>
+ The output directory where the artifacts are written is defined by the
+ property
+ <literal>org.jboss.testharness.outputDirectory</literal>
+ . The jboss-tck-runner project is configured to dump the artifacts to
+ the target/jsr299-artifacts directory.
+ </para>
+ <para>
+ 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
+ <literal>methodName</literal>
+ request parameter (e.g., ?methodName=testMethodName).
+ </para>
+ </section>
</chapter>