[webbeans-commits] Webbeans SVN: r3202 - tck/trunk/doc/reference/en-US.
webbeans-commits at lists.jboss.org
webbeans-commits at lists.jboss.org
Fri Jul 24 14:45:06 EDT 2009
Author: pete.muir at jboss.org
Date: 2009-07-24 14:45:06 -0400 (Fri, 24 Jul 2009)
New Revision: 3202
Modified:
tck/trunk/doc/reference/en-US/executing.xml
tck/trunk/doc/reference/en-US/installation.xml
Log:
Shift a few things around in executing
Modified: tck/trunk/doc/reference/en-US/executing.xml
===================================================================
--- tck/trunk/doc/reference/en-US/executing.xml 2009-07-24 18:28:01 UTC (rev 3201)
+++ tck/trunk/doc/reference/en-US/executing.xml 2009-07-24 18:45:06 UTC (rev 3202)
@@ -11,33 +11,24 @@
</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
+ includes a TCK runner project that executes the CDI TCK on the
+ Web Beans running inside JBoss AS 5.1. To execute the
+ CDI TCK on your own JSR-299 implementation, you could modify the TCK
runner project included with Web Beans to use your JSR-299
implementation as described in
- <xref linkend="tck-harness-properties" />
+ <xref linkend="configuration" />
</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 execute the TCK test suite against the Web Beans, first switch
to the jboss-tck-runner directory in the extracted Web Beans
distribution:
</para>
@@ -64,17 +55,10 @@
<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:
+ runner, you first have to setup JBoss AS as described in <xref linkend="tck-in-jboss-as"/>.
</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:
+ Then, execute the TCK runner:
</para>
<programlisting>mvn test -Dincontainer</programlisting>
<para>
@@ -97,12 +81,8 @@
<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>
@@ -115,55 +95,18 @@
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.
+ servlet-based communication over HTTP as described in <xref linkend="incontainer-communication"/>
</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
+ packaging. When investigating a test failure, it's helpful to be able
+ to inspect the artifact after it is generated. The TCK can accommodate
this type of inspection by "dumping" the generated artifact to disk.
</para>
<para>
Modified: tck/trunk/doc/reference/en-US/installation.xml
===================================================================
--- tck/trunk/doc/reference/en-US/installation.xml 2009-07-24 18:28:01 UTC (rev 3201)
+++ tck/trunk/doc/reference/en-US/installation.xml 2009-07-24 18:45:06 UTC (rev 3202)
@@ -62,15 +62,9 @@
</section>
<section>
- <title>Installing the Software</title>
+ <title>The TCK Environment</title>
<para>
- Installing Java software is a bit of a misnomer. The only software
- you have to "install" are the runtime environments. The
- remaining software is merely extracted in a workspace directory of your
- choice.
- </para>
- <para>
The TCK requires the following two Java runtime environments:
</para>
<itemizedlist>
@@ -107,7 +101,18 @@
webbeans/
tck/]]></programlisting>
- <tip>
+ <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>
+
+ <tip id="tck-in-jboss-as">
<title>
Running the TCK against the CDI RI (Web Beans) and JBoss AS
</title>
More information about the weld-commits
mailing list