The test suite is executed by the Maven Surefire plugin during the test phase of the Maven life cycle. The execution happens within a TCK runner project (as opposed to the TCK project itself). Weld includes a TCK runner project that executes the CDI TCK on Weld running inside WildFly 8.x. To execute the CDI TCK on your own CDI implementation, you could modify the TCK runner project included with Weld to use your CDI implementation.

To execute the TCK test suite against Weld, first switch to the jboss-tck-runner directory in the extracted TCK distribution:

cd jsr346/tck/weld/jboss-tck-runner

Then execute the Maven life cycle through the test phase:

mvn test

Without any command-line flags, the test suite is run in standalone mode (activating weld-embedded Maven profile), which means that any test within the integration or javaee-full TestNG group is excluded. This mode uses the Weld EE Embedded Arquillian container adapter to invoke the test 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 using the in-container mode.

To execute the test suite using in-container mode with the JBoss TCK runner, you first have to setup WildFly as described in the Running the TCK against the CDI RI callout.

Then, execute the TCK runner with Maven as follows:

mvn test -Dincontainer

The presence of the incontainer property activates an incontainer Maven profile. This time, all the tests in the test suite are executed.

In order to run tests appropriate to the Java EE Web Profile execute:

mvn test -Dincontainer=webprofile

To specify particular TCK version:

mvn test -Dincontainer -Dcdi.tck.version=1.1.0.SP2

The Arquillian will also start and stop the application server automatically (provided a managed Arqullian container adapter is used).

Since Arquillian 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 TCK utilizes servlet-based protocol (communication over HTTP).

As you have learned, when the test suite is executing using in-container mode, each test class is packaged as a deployable archive and deployed to the container. The test is then executed within the context of the deployed application. This leaves room for errors in packaging. When investigating a test failure, you may find it helpful to inspect the archive after it's generated. The TCK (or Arquillian respectively) can accommodate this type of inspection by "dumping" the generated archive to disk.

The feature just described is activated in the Arquillian configuration file (Section 4.2, “Arquillian settings”). In order to export the test archive you'll have to add the deploymentExportPath property element inside engine element and assign a relative or absolute directory where the test archive should be exported, e.g.:

            <engine>
                <property name="deploymentExportPath">target/</property>
            </engine>
         

Arquillian will export the archive to that location for any test you run.

To enable the export for just a single test, use the VM argument arquillian.deploymentExportPath:

-Darquillian.deploymentExportPath=target/deployments/