To run the signature test simply change the execution command from Setup to SignatureTest:

java -jar sigtestdev.jar SignatureTest -classpath "%JAVA_HOME%\jre\lib\rt.jar:lib/cdi-api.jar:lib/javax.inject.jar:lib/el-api.jar:lib/jboss-interceptor-api.jar" -Package javax.decorator -Package javax.enterprise -FileName artifacts/cdi-tck-impl-sigtest.sig -static

When running the signature test, you may get the following message:

"The return type java.lang.reflect.Member can't be resolved"

This can safely be ignored - the important thing is to get the "STATUS:Passed." message.

Just for fun (and to confirm that the signature test is working correctly), you can try the following:

1) Edit cdi-api.sig

2) Modify one of the class signatures - in the following example we change one of the constructors for BusyConversationException - here’s the original:

CLSS public javax.enterprise.context.BusyConversationException
cons public BusyConversationException()
cons public BusyConversationException(java.lang.String)
cons public BusyConversationException(java.lang.String,java.lang.Throwable)
cons public BusyConversationException(java.lang.Throwable)
supr javax.enterprise.context.ContextException
hfds serialVersionUID

Let’s change the default (empty) constructor parameter to one with a java.lang.Integer parameter instead:

CLSS public javax.enterprise.context.BusyConversationException
cons public BusyConversationException(java.lang.Integer)
cons public BusyConversationException(java.lang.String)
cons public BusyConversationException(java.lang.String,java.lang.Throwable)
cons public BusyConversationException(java.lang.Throwable)
supr javax.enterprise.context.ContextException
hfds serialVersionUID

3) Now when we run the signature test using the above command, we should get the following errors:

Missing Constructors
--------------------

javax.enterprise.context.BusyConversationException:         constructor public javax.enterprise.context.BusyConversationException.BusyConversationException(java.lang.Integer)

Added Constructors
------------------

javax.enterprise.context.BusyConversationException:         constructor public javax.enterprise.context.BusyConversationException.BusyConversationException()


STATUS:Failed.2 errors

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

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.

Using an existing test harness (TestNG) allows the tests to be executed and debugged in an Integrated Development Environment (IDE) using available plugins. Using an IDE is also the easiest way to execute a test class in isolation.

When setting up your Eclipse workspace, we recommended creating three workings sets:

Weld - Groups the CDI API and the CDI RI (i.e., Weld) projects CDI TCK - Groups the CDI TCK API and the test suite projects Weld JBoss TCK Runner - Groups the porting package implementation and TCK runner projects The dependencies between the projects will either be established automatically by the m2e plugin, based on the dependency information in the pom.xml files, or as generated by the mvn eclipse:eclipse command.

Your workspace should appear as follows:

Weld
  cdi-api
  weld-core
  ...
CDI TCK
  cdi-tck-api
  cdi-tck-impl
  cdi-tck-parent
Weld JBoss TCK Runner
  weld-jboss-runner-tck
  weld-porting-package-tck

The tests in the TCK test suite are located in the cdi-tck-impl project. You’ll be working within this project in Eclipse when you are developing tests. However, as you learned earlier, there are no references to a CDI 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 cdi-tck-impl project and your TCK runner project, which in this case is weld-jboss-runner-tck (the project in the jboss-tck-runner/1.1 directory).

Here are the steps to establish the link:

Of course, the weld-jboss-runner-tck also depends on the cdi-tck-impl at runtime (so it can actually find the tests to execute). But m2e plugin doesn’t distinguish between build-time and runtime dependencies. As a result, we’ve created a circular dependency between the projects. In all likelihood, Eclipse will struggle (if not fail) to compile one or more projects. How can we break this cycle?

As it turns out, the TCK runner doesn’t need to access the tests to build. It only needs its classes, configurations and other dependencies at runtime (when the TestNG plugin executes). Therefore, we can disable Resolve dependencies from workspace projects setting on weld-jboss-runner-tck project:

As you have learned, the TCK determines how to behave based on the values of system properties or properties defined in META-INF/cdi-tck.properties classpath resources. In order to run the tests, you need to add a properties file to the classpath or define corresponding system properties.

The CDI TCK project conveniently provides the properties file src/test/resources/META-INF/cdi-tck.properties that contains all of the necessary properties for testing in Eclipse. You have to tune the org.jboss.cdi.tck.libraryDirectory and org.jboss.cdi.tck.testDataSource properties to point to the relative location of the related projects and specify the name of test datasource. The properties should be defined as follows:

org.jboss.cdi.tck.libraryDirectory - the path to the target/dependency/lib directory in the TCK runner project org.jboss.cdi.tck.testDataSource - the JNDI name of the test datasource, e.g. WildFly 8:

org.jboss.cdi.tck.testDataSource=java:jboss/datasources/ExampleDS

You are now ready to execute an individual test class (or artifact). Let’s start with a test artifact capable of running in standalone mode.

Use weld-embedded Maven profile (active by default) in order to run a test in standalone mode.

Select a test class containing standalone tests and open it in the Eclipse editor. Now right click in the editor view and select Run As > TestNG Test. The TestNG view should pop out and you should see all the tests in that artifact pass (if all goes well).

So far you have executed a test in standalone mode. That’s not sufficient to pass the TCK. The test must be executed using in-container mode.

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 WildFly if you are using the JBoss TCK runner.

In order to run a test in the container you must explicitly specify following active Maven profiles in JBoss TCK runner Eclipse project properties: incontainer,!weld-embedded.

Select an integration test (a class that extends org.jboss.cdi.tck.AbstractTest and open it in your Eclipse editor. Right click in the editor view and select Run As > TestNG Test.

You have now mastered running the CDI TCK against Weld using both Maven and within Eclipse. Now you’re likely interested in how to debug a test so that you can efficiently investigate test failures.

There is almost no difference in how you debug a standalone test from how you run it. With the test class open in the Eclipse editor, simply right click in the editor view and select Debug As > TestNG Test. Eclipse will stop at any breakpoints you set just like it would with any other local debug process.

If you plan to step into a class in the Weld implementation (or any other dependent library), you must ensure that the source is properly associated with the library. Below are the steps to follow to associate the source of Weld with the TestNG debug configuration:

You’ll have to complete those steps for any test class you are debugging, though you only have to do it once (the debug configuration hangs around indefinitely).

Again, running a test in standalone mode isn’t enough to pass the TCK and cannot be used to run or debug an integration test. Let’s look at how to debug a test running in the context of the container.