[webbeans-commits] Webbeans SVN: r3200 - tck/trunk/doc/reference/en-US.

Author: pete.muir(a)jboss.org Date: 2009-07-24 14:18:19 -0400 (Fri, 24 Jul 2009) New Revision: 3200 Modified: tck/trunk/doc/reference/en-US/ tck/trunk/doc/reference/en-US/configuration.xml tck/trunk/doc/reference/en-US/master.xml tck/trunk/doc/reference/en-US/part-execution.xml tck/trunk/doc/reference/en-US/part-test-harness.xml Log: Split out JBoss Test Harness config chapter Property changes on: tck/trunk/doc/reference/en-US ___________________________________________________________________ Name: svn:externals - harness http://anonsvn.jboss.org/repos/test-utils/jboss-test-harness/trunk/doc/re... + harness https://svn.jboss.org/repos/test-utils/jboss-test-harness/trunk/doc/refer... Modified: tck/trunk/doc/reference/en-US/configuration.xml =================================================================== --- tck/trunk/doc/reference/en-US/configuration.xml 2009-07-24 16:24:33 UTC (rev 3199) +++ tck/trunk/doc/reference/en-US/configuration.xml 2009-07-24 18:18:19 UTC (rev 3200) @@ -3,50 +3,37 @@ <chapter id="configuration"> <title>Configuration</title> <para> - This chapter lays out how to configure the JBoss Test Harness by - specifying the SPI implementation classes, defining the target container - connection information, and various other switches. You then learn how to - setup a TCK runner project that executes the the TCK test suite, putting - these settings into practice. Finally, a detailed account of how the JBoss - Test Harness negotiates the execution of the tests in the container is - given. + This chapter lays out how to configure the TCK Harness by specifying + the SPI implementation classes, defining the target container connection + information, and various other switches. You then learn how to setup a TCK + runner project that executes the the TCK test suite, putting these + settings into practice. Finally, a detailed account of how the JBoss Test + Harness negotiates the execution of the tests in the container is given. </para> - <section id="test-harness-properties"> - <title>JBoss Test Harness Properties</title> + + <para> + This guide does not discuss in detail how to use the TCK in standalone + mode. The JBoss Test Harness guide provides more on running in standalone + mode. + </para> + <section id="tck-harness-properties"> + <title>TCK Harness Properties</title> <para> The JBoss Test Harness allows the test suite to be launched in a pluggable fashion. In order to execute the TCK, the JBoss Test Harness must be configured by specifying implementations of the test launcher - and container APIs. All the required configuration that pertains to the - JBoss Test Harness is applicable to the TCK as well. + and container APIs. </para> <para> System properties and/or the resource <code>META-INF/jboss-test-harness.properties</code> , a Java properties file, are used to configure the JBoss Test Harness. - The bootstrap configuration builder looks to the property - <literal>org.jboss.testharness.api.ConfigurationBuilder</literal> - , the first property listed in table 3.1, for the fully qualified class - name (FQCN) of a concrete configuration builder implementation to get - started. This implementation loads the remaining configuration settings - and produces a JBoss Test Harness configuration. + You can read more about configuring the JBoss Test Harness in + <xref linkend="test-harness-properties" /> </para> <para> - For you convenience, the default configuration builder implementation - <literal>org.jboss.testharness.impl.PropertiesBasedConfigurationBuilder - </literal> - is provided, which collects all the JBoss Test Harness configuration - settings from Java properties. It does so by aggregating the system - properties with the properties defined in the - META-INF/jboss-test-harness.properties resource in any classpath entry - under a single properties map, allowing you to partition the - configuration settings as needed. + You should set the following properties </para> - <para> - A complete list of configuration properties for the JBoss Test - Harness has been itemized in table 2.1.1, accompanied by the default - value (if any) and a description for each property. - </para> <table frame="all"> <title /> <tgroup cols="2"> @@ -54,225 +41,81 @@ <colspec colnum="2" colname="description" colwidth="2*" /> <thead> <row> - <entry>Property = Default Value</entry> + <entry>Property = Required/Example Value</entry> <entry>Description</entry> </row> </thead> <tbody> <row> <entry> - <literal>org.jboss.testharness.api.ConfigurationBuilder= + <literal>org.jboss.testharness.libraryDirectory=/path/to/extra/libraries </literal> - <literal>o.j.t.impl.PropertiesBasedConfigurationBuilder - </literal> </entry> <entry> - The configuration bootstrap class for the JBoss Test - Harness. + Directory containing extra JARs you want placed in + artifact library directory such as the porting package + implementation. </entry> </row> <row> <entry> - <literal>org.jboss.testharness.testPackage=</literal> + <literal>org.jboss.testharness.standalone=false</literal> </entry> <entry> - The top-level Java package containing the classes to be - tested. + You must run the tests in-container to pass the TCK </entry> </row> <row> <entry> - <literal>org.jboss.testharness.libraryDirectory=</literal> + <literal>org.jboss.testharness.runIntegrationTests=true + </literal> </entry> <entry> - Directory containing extra JARs. + You must run the integration tests to pass the TCK </entry> </row> <row> <entry> - <literal>org.jboss.testharness.standalone=true</literal> - </entry> - <entry> - Tests are run using standalone mode if true or using - in-container mode if false. - </entry> - </row> - <row> - <entry> - <literal>org.jboss.testharness.runIntegrationTests=false + <literal>org.jboss.testharness.spi.Containers=com.acme.AcmeContainer </literal> </entry> <entry> - If true, integration tests are run. In-container mode - must be activated. - </entry> - </row> - <row> - <entry> - <literal>org.jboss.testharness.spi.Containers=</literal> - </entry> - <entry> The container implementation for deploying and - executing in-container tests. + executing + in-container tests. See + <xref linkend="deployment-api-contributions" /> </entry> </row> <row> <entry> - <literal>org.jboss.testharness.host=localhost:8080 + <literal>org.jboss.testharness.api.TestLauncher=org.jboss.testharness.impl.runner.servlet.ServletTestLauncher </literal> </entry> <entry> - The host and port on which the container is running. + You should use the + <literal>ServletTestLauncher</literal> + for Java EE6 and Java EE6 Web Profile. </entry> </row> - <row> - <entry> - <literal>org.jboss.testharness.connectDelay=5000</literal> - </entry> - <entry> - The timeout (ms) when attempting to connect to the - container. - </entry> - </row> - <row> - <entry> - <literal>org.jboss.testharness.connectRetries=2</literal> - </entry> - <entry> - The number of connection retries used when connecting - the the container. - </entry> - </row> - <row> - <entry> - <literal>org.jboss.testharness.api.TestLauncher=</literal> - </entry> - <entry> - The in-container test launcher. - </entry> - </row> - <row> - <entry> - <literal>org.jboss.testharness.container.\</literal> - <literal>deploymentExceptionTransformer=</literal> - </entry> - <entry> - A class which maps deployment exceptions to expected - exceptions declared in test case. Returns original - exception by default. - </entry> - </row> - <row> - <entry> - <literal>org.jboss.testharness.container.forceRestart=false - </literal> - </entry> - <entry> - Whether the container should be restarted before the - tests are executed. - </entry> - </row> - <row> - <entry> - <literal>org.jboss.testharness.container.extraConfigurationDir= - </literal> - </entry> - <entry> - A directory containing a build.properties or - local.build.properties files that define additional - properties. - </entry> - </row> - <row> - <entry> - <literal>org.jboss.testharness.spi.StandaloneContainers= - </literal> - </entry> - <entry> - The container implementation for executing standalone - tests. - </entry> - </row> - <row> - <entry> - <literal>dumpArtifacts=false</literal> - </entry> - <entry> - Whether the test artifacts should be written to disk - for inspection. - </entry> - </row> - <row> - <entry> - <literal>org.jboss.testharness.outputDirectory=</literal> - <literal>%java.io.tmpdir%/jsr-299-tck/</literal> - </entry> - <entry> - Directory where test artifacts will be written to disk, if - <literal>dumpArtifacts</literal> - is true. - </entry> - </row> </tbody> </tgroup> </table> <para> - The TCK also relies on implementations of the interfaces in the - porting package. These implementations are also specified using system - properties or the classpath resource - META-INF/jboss-test-harness.properties. The implementation of each - porting package SPI must be specified using the fully-qualified domain - name (FQDN) of the interface mapped to a Java property. The properties - that correspond to the interface which must be implemented are listed - in table 3.2. + To run the full TCK you must additionally implement + <literal>org.jboss.testharness.spi.Containers</literal> + , which handles deploying the test artifact to the container. An + implementations of this API is already available for JBoss AS 5.1. + Therefore, you only need to implement this part of the porting package + if you wish to use another container. </para> - <table frame="all"> - <title /> - <tgroup cols="2"> - <colspec colname="property" /> - <colspec colname="description" /> - <thead> - <row> - <entry>Property</entry> - <entry>Description</entry> - </row> - </thead> - <tbody> - <row> - <entry> - <literal>org.jboss.jsr299.tck.spi.Managers</literal> - </entry> - <entry> - Operations pertaining to the BeanManager. - </entry> - </row> - <row> - <entry> - <literal>org.jboss.jsr299.tck.spi.Beans</literal> - </entry> - <entry> - Operations pertaining to bean types. - </entry> - </row> - <row> - <entry> - <literal>org.jboss.jsr299.tck.spi.Contexts</literal> - </entry> - <entry> - Operations pertaining to Java EE contexts. - </entry> - </row> - <row> - <entry> - <literal>org.jboss.jsr299.tck.spi.EL</literal> - </entry> - <entry> - Operations pertaining to the Unified EL. - </entry> - </row> - </tbody> - </tgroup> - </table> + <note id="deployment-api-contributions"> + <para> + Red Hat Middleware LLC encourages CDI implementators to + contribute JBoss Test Harness Deployment API implementations for + other containers under the ASL license. Please contact the CDI TCK + lead. + </para> + </note> </section> <section> <title>The Porting Package</title> @@ -322,355 +165,59 @@ provided. </para> - <para> - To run the full TCK you must additionally implement - <literal>org.jboss.testharness.spi.Containers</literal> - , which handles deploying the test artifact to the container. An - implementations of this API is already available for JBoss AS 5.1. - Therefore, you only need to implement this part of the porting package - if you wish to use another container. - </para> - <note> - <para> - Red Hat Middleware LLC encourages CDI implementators to - contribute JBoss Test Harness Deployment API implementations for - other containers under the ASL license. Please contact the CDI TCK - lead. - </para> - </note> - <para> - If you wish to run the TCK in standalone mode, a CDI implementation - must provide an implementation of - <literal>org.jboss.testharness.spi.StandaloneContainers</literal> - . The CDI RI provides an implementation of this API; see the RI - reference guide. - </para> - <para> - The default configuration for the TCK uses Java properties files. The - implementation class for all of these SPIs is placed in this properties - file. Optionally, you can use system properties to configure the TCK. - Details are provided in - <xref linkend="test-harness-properties" /> - . - </para> </section> + <section> - <title>Setting up the TCK runner project</title> + <title>Configuring TestNG to execute the TCK</title> <para> - The TCK runner project is the magic that makes everything come - together and allows you to execute the TCK against a JSR-299 - implementation. If you fully understand how the JBoss Test Harness - functions, and have a good grasp on Maven 2, then it&apos;s not to - difficult to understand how the TCK runner project works. Regardless of - your background, this guide covers what you need to know to get up and - running by studying the TCK runner that tests the JSR-299 RI. + The JBoss Test Harness is built on top of TestNG, and it is TestNG that + is responsible for selecting the tests to execute, the order of + execution, and reporting the results. Detailed TestNG documentation can + be found at + <ulink url="http://testng.org/doc/documentation-main.html">testng.o... + . </para> <para> - The TCK runner for the JSR-299 RI can be found in the - jboss-tck-runner directory in the Web Beans distribution. The - dependencies of the TCK runner project for the JSR-299 RI are listed in - table 2.2.3. + The + <literal>tck-tests.xml</literal> + artifact provided in the TCK distribution must be run by TestNG 5.9 + (described by the TestNG documenation as "with a + <literal>testng.xml</literal> + file") unmodified for an implementation to pass the TCK. This file also + allows test to be excluded from a run: </para> - <table frame="all"> - <title /> - <tgroup cols="3"> - <colspec colname="c1" /> - <colspec colname="c2" /> - <colspec colname="c3" /> - <thead> - <row> - <entry>Group ID</entry> - <entry>Artifact ID</entry> - <entry>Version</entry> - </row> - </thead> - <tbody> - <row> - <entry>org.jboss.webbeans</entry> - <entry>jsr299-api</entry> - <entry>1.0.0-SNAPSHOT</entry> - </row> - <row> - <entry>org.jboss.jsr299.tck</entry> - <entry>jsr299-tck-api</entry> - <entry>1.0.0-SNAPSHOT</entry> - </row> - <row> - <entry>org.jboss.jsr299.tck</entry> - <entry>jsr299-tck-impl</entry> - <entry>1.0.0-SNAPSHOT</entry> - </row> - <row> - <entry>org.jboss.webbeans</entry> - <entry>webbeans-core</entry> - <entry>1.0.0-SNAPSHOT</entry> - </row> - <row> - <entry>org.jboss.webbeans</entry> - <entry>webbeans-porting-package</entry> - <entry>1.0.0-SNAPSHOT</entry> - </row> - <row> - <entry>org.testng</entry> - <entry>testng (classifier: jdk15)</entry> - <entry>5.8</entry> - </row> - <row> - <entry>org.jboss.test-harness</entry> - <entry>jboss-test-harness-jboss-as-51</entry> - <entry>1.0.0.BETA3</entry> - </row> - </tbody> - </tgroup> - </table> + <programlisting><![CDATA[<suite name="JSR-299 TCK" verbose="2" > + <test name="JSR-299 TCK" > + ... + <classes> + <class name="org.jboss.jsr299.tck.tests.context.application.ApplicationContextTest"> + <methods> + <exclude name=" testApplicationScopeActiveDuringServiceMethod" /> + </methods> + </class> + </classes> + ... + </test> +</suite>]]></programlisting> + <para> - You can install these dependencies manually into your local Maven - respository using the following command template: + TestNG provides extensive reporting information; depending on the + build tool or IDE you use the reporting will take a different format. + Please consult the TestNG documentation and the tool documentation for + more information. </para> - <programlisting>mvn install:install-file \ --Dfile=jsr299-tck-api.jar \ --DgroupId=org.jboss.jsr299.tck \ --DartifactId=jsr29-tck-api \ --Dversion=1.0.0-SNAPSHOT \ --Dpackaging=jar</programlisting> - <para> - You should substituate the webbeans-core and webbeans-porting-package - artifacts from table 2.2.3 if you are running the TCK against your - JSR-299 implementation. You&apos;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 - <literal>Containers</literal> - SPI for the JBoss Test Harness. - </para> - <note> - <para> - When running the TCK in the in-container mode, the tests will run - against the JSR-299 implementation installed in the container. The - version of the implementation declared as a Maven dependency is only - used when running the TCK in standalone mode. - </para> - </note> - <para> - The TestNG test suite for the TCK is also retrieved from the local - Maven repository (groupId=org.jboss.jsr299.tck, - artifactId=jsr299-tck-impl, classifier=suite, type=xml, - version=1.0.0-SNAPSHOT), but it&apos;s not declared as a regular Maven - dependency. That&apos;s because the test suite must be available to - both the client JVM and the container JVM. The maven-dependency-plugin - is used to copy it to the target/dependencies/lib directory. Any JARs - in this folder are added to any test artifact that is generated. The - Maven plugin execution is defined in the TCK runner project as follows: - </para> - <programlisting><![CDATA[<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.webbeans</groupId> - <artifactId> - webbeans-porting-package - </artifactId> - <overWrite>true</overWrite> - <outputDirectory> - ${project.build.directory}/dependency/lib - </outputDirectory> - </artifactItem> - <artifactItem> - <groupId>org.jboss.webbeans</groupId> - <artifactId>webbeans-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>]]></programlisting> - <para> - The target folder is declared as the JBoss Test Harness library - directory so - that the JARs are added to the test artifact using the - following - property assignment: - </para> - <programlisting>org.jboss.testharness.libraryDirectory=target/dependency/lib</programlisting> - <para> - 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 - <literal>incontainer</literal> - profile enables integration tests and disables standalone mode, - changing the default settings. - </para> - <para> - The jboss-tck-runner project also defines the JBoss Test Harness - extra configuration directory using the following property: - </para> - <programlisting>org.jboss.testharness.container.extraConfigurationDir=../jboss-as</programlisting> - <para> - 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 - <literal>jboss.home</literal> - property for starting and stopping JBoss AS. - </para> </section> + <section> - <title>Negotiating the execution of an in-container test</title> + <title>Configuring your build environment to execute the TCK</title> <para> - The basic procedure of an in-container test is as follows. The JBoss - Test Harness produces a deployable artifact from an - <literal>@Artifact</literal> - test class and any declared dependent classes, descriptors or other - resources. Then it deploys the artifact to the container using the - <literal>Containers</literal> - SPI, negotiates with the container to execute the test and return the - result and, lastly, undeploys the artifact. TestNG collects the results - of all the tests run in the typical way and produces a report. + It is beyond the scope of this guide to describe in how to set up your + build environment to run the TCK. The JBoss Test Harness guide + describes how to Web Beans uses Maven 2 to execute the CDI TCK. See + <xref linkend="testsuite-runner" /> + . The TestNG provides extensive information on launching TestNG using + the Java, ant, Eclipse or IntellJ IDEA. </para> - <graphic fileref="images/in-container-execution.png" align="center" /> - <para> - The question is, how does the JBoss Test Harness negotiate with the - container to execute the test when TestNG is being invoked locally? - Technially the mechanism is pluggable, but JBoss Test Harness provides - a default implementation that uses HTTP communication that you will - likely use. Here&apos;s how the default implementation works. - </para> - <para> - The artifact generator bundles and registers (in the web.xml - descriptor) an - <literal>HttpServlet</literal> - , - <literal>org.jboss.testharness.impl.runner.servlet.ServletTestRunner - </literal> - , that responds to test execution GET requests. TestNG running on the - client side delegates to a test launcher (more on that in a moment) - which originates these text execution requests to transfer control to - the container JVM. The name of the test method to be executed is - specified in a request query parameter named - <literal>methodName</literal> - . - </para> - <para> - When the test execution request is received, the servlet delegates to - an instance of - <literal>org.jboss.testharness.impl.runner.TestRunner</literal> - , passing it the name of the test method. - <literal>TestRunner</literal> - reads the name of the test class from the resource - META-INF/jboss-test-harness.properties, which is bundled in the - artifact by the artifact generator. It then combines the class name - with the method name to produce a TestNG test suite and runs the suite - (in the context of the container). - </para> - <para> - TestNG returns the results of the run as an - <literal>ITestResult</literal> - object. - <literal>ServletTestRunner</literal> - translates this object into a - <literal>org.jboss.testharness.api.TestResult</literal> - and passes it back to the test launcher on the client side by encoding - the translated object into the response. The object gets encoded as - either html or a serialized object, depending on the value of the - <literal>outputMode</literal> - request parameter that was passed to the servlet. Once the result has - been transfered to the client-side TestNG, TestNG wraps up the run of - the test as though it had been executed in the same JVM. - </para> - <para> - There&apos;s - one piece missing. How does TestNG on the client side know - to submit a - request to the - <literal>ServletTestRunner</literal> - servlet to get TestNG to execute the test in the container JVM? - That&apos;s the role of the test launcher. - </para> - <para> - The test launcher is the API that allows test suite to launch the test - in a pluggable fashion. - <literal>AbstractTest</literal> - , the super class of - <literal>AbtractJSR299Test</literal> - , implements - <literal>IHookable</literal> - , a TestNG interface which allows the execution of the test method to - be intercepted. Using that mechanism, AbstractTest delegates execution - of the test method (a method annotated with - <literal>@Test</literal> - in an - <literal>@Artifact</literal> - class) to an implementation of - <literal>org.jboss.testharness.api.TestLauncher</literal> - if the tests are being executed in-container. As you might anticipate, - the implementation is specified using a property with the same name as - the interface in a META-INF/jboss-test-launcher.properties resource. - The JBoss Test Harness provides a default implementation, - <literal>org.jboss.testharness.impl.runner.servlet.ServletTestLauncher - </literal> - , that hooks into the HTTP communication infrastructure described - above. It invokes the - <literal>ServletTestRunner</literal> - servlet for each method annotated with - <literal>@Test</literal> - in the - <literal>@Artifact</literal> - that is not otherwise disabled. - </para> - <para> - If you wish to implement the runner yourself, you must return a - <literal>TestResult</literal> - as a result of executing the method in the container. You must also - ensure that any exception which occurs during deployment is wrapped as - a - <literal>org.jboss.testharness.api.DeploymentException</literal> - , and that any communication problem is rethrown as an - <literal>IOException</literal> - . The deployment exception may be transformed by an implementation of - the - <literal>org.jboss.testharness.api.DeploymentExceptionTransformer - </literal> - interface, which is specified using the - <literal>org.jboss.testharness.container.deploymentExceptionTransformer - </literal> - property. The default implementation passes on the original exception - unchanged. - </para> - <para> - So in short, JBoss Test Harness takes care of all the interfaces you - need to execute tests in-container except for the implementation of the - <literal>Containers</literal> - SPI. That is, unless you are deploying to one of the containers - supported by the JBoss Test Harness. - </para> + </section> </chapter> Modified: tck/trunk/doc/reference/en-US/master.xml =================================================================== --- tck/trunk/doc/reference/en-US/master.xml 2009-07-24 16:24:33 UTC (rev 3199) +++ tck/trunk/doc/reference/en-US/master.xml 2009-07-24 18:18:19 UTC (rev 3200) @@ -4,7 +4,7 @@ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="Book_Info.xml"/> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="Book_Preface.xml"/> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="part-background.xml"/> - <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="part-test-harness.xml" /> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="part-setup.xml"/> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="part-execution.xml"/> + <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="part-test-harness.xml" /> </book> Modified: tck/trunk/doc/reference/en-US/part-execution.xml =================================================================== --- tck/trunk/doc/reference/en-US/part-execution.xml 2009-07-24 16:24:33 UTC (rev 3199) +++ tck/trunk/doc/reference/en-US/part-execution.xml 2009-07-24 18:18:19 UTC (rev 3200) @@ -4,12 +4,12 @@ <title>Executing and Debugging Tests</title> <partintro> <para> - In this part you learn how to execute the JSR-299 TCK on a given - JSR-299 implementation. First, you are walked through the steps - necessary to execute the test suite on the JSR-299 RI (Web Beans). Then - you discover how to modify the TCK runner to execute the test suite on - your own implementation. Finally, you learn how to debug tests from the - test suite in Eclipse. + In this part you learn how to execute the CDI TCK on the CDI + reference implementation (Web Beans). First, you are walked through the + steps necessary to execute the test suite on the Web Beans. Then you + discover how to modify the TCK runner to execute the test suite on your + own implementation. Finally, you learn how to debug tests from the test + suite in Eclipse. </para> </partintro> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="executing.xml" /> Modified: tck/trunk/doc/reference/en-US/part-test-harness.xml =================================================================== --- tck/trunk/doc/reference/en-US/part-test-harness.xml 2009-07-24 16:24:33 UTC (rev 3199) +++ tck/trunk/doc/reference/en-US/part-test-harness.xml 2009-07-24 18:18:19 UTC (rev 3200) @@ -4,9 +4,11 @@ <title>JBoss Test Harness</title> <partintro> <para> - In this part you learn about the JBoss Test Harness. You can view the + In this part you learn about the JBoss Test Harness through selected + chapters from the JBoss Test Harness Reference Guide. You can view the entire JBoss Test Harness Reference Guide at <ulink url="">TODO</ulink>. </para> </partintro> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="harness/introduction.xml" /> + <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="harness/configuration.xml" /> </part>