[webbeans-commits] Webbeans SVN: r3201 - tck/trunk/doc/reference/en-US.
webbeans-commits at lists.jboss.org
webbeans-commits at lists.jboss.org
Fri Jul 24 14:28:01 EDT 2009
Author: pete.muir at 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>@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">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>@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>
More information about the weld-commits
mailing list