SeamFramework.orgCommunity Documentation

Chapter 7. Running Tests in Eclipse

7.1. Leveraging Eclipse's plugin ecosystem
7.2. Readying the Eclipse workspace
7.3. Running a test in standalone mode
7.4. Running integration tests

This chapter explains how to run individual tests using the Eclipse TestNG plugin. It covers running non-integration tests in standalone mode and integration tests (as well as non-integration tests) in in-container mode. You should be able to use the lessons learned here to debug tests in an alternate IDE as well.

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.

The TCK can be executed in any IDE for which there is a TestNG plugin available. Running a test from the CDI TCK test suite using the Eclipse TestNG plugin is almost as simple as running any other TestNG test. You can also use the plugin to debug a test, which is described in the next chapter.

Before running a test from the TCK test suite in Eclipse, you must have the Eclipse TestNG plugin and either the m2eclipse plugin or an Eclipse project generated use the Maven 2 Eclipse plugin (maven-eclipse-plugin). Refer to Section 3.3, “Eclipse Plugins” for more information on these plugins.

With the m2eclipse plugin installed, Eclipse should recognize the CDI TCK projects as valid Eclipse projects (or any Weld project for that matter). Import them into the Eclipse workspace at this time. You should also import the Weld projects if you want to debug into that code, which is covered later.


If you choose to use the Maven 2 Eclipse plugin (maven-eclipse-plugin), you should execute the plugin in both the tck and weld projects:

cd tck
mvn clean eclipse:clean eclipse:eclipse -DdownloadSources -DdownloadJavadocs
cd ../weld
mvn clean eclipse:clean eclipse:eclipse -DdownloadSources -DdownloadJavadocs

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

The dependencies between the projects will either be established automatically by the m2eclipse 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 JBoss TCK Runner

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, 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 jsr299-tck-impl project and your TCK runner project, which in this case is weld-jboss-tck-runner (the project in the jboss-tck-runner directory).

Here are the steps to establish the link:

Of course, the weld-jboss-tck-runner also depends on the jsr299-tck-impl at runtime (so it can actually find the tests to execute). But Eclipse 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 dependenices at runtime (when the TestNG plugin executes). Therefore, we can remove the TCK runner's dependence on the jsr299-tck-impl project by following these steps:

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.

A standalone test artifact is a class which extends AbstractJSR299Test, is annotated with @Artifact, but is not annotated with @IntegrationTest. Select a standalone test artifact 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. Using in-container mode is also the only way to execute a test annotated with @IntegrationTest (that's what the annotation means) as it requires container resources.

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.

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/ classpath resources. If the property named org.jboss.testharness.standalone 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.

The JBoss TCK runner project conveniently provides the properties file src/test/debug-resources/META-INF/ that contains all of the necessary properties for in-container testing in Eclipse. Assuming you followed the directory structure recommended in Section 3.2, “The TCK Environment”, you are good to go. Otherwise, you may have to tune the org.jboss.testharness.container.extraConfigurationDir and org.jboss.testharness.libraryDirectory properties to point to the relative location of the related projects. The properties should be defined as follows:

  • org.jboss.testharness.container.extraConfigurationDir - the relative path from the jboss-tck-impl project to a directory that contains a or file defining the location of a JBoss AS 5.1 installation in the jboss.home property

  • org.jboss.testharness.libraryDirectory - the relative path from the jboss-tck-impl project to the target/dependency/lib directory in the TCK runner project.

The other properties in that file are defined as follows:


You're now ready to execute an integration test. Select an integration test (a class that extends AbstractJSR299Test and is annotated with both @Artifact and @IntegrationTest) and open it in your Eclipse editor. Follow these steps to execute the class with the TestNG plugin:

  1. Right click in the editor view and select Run As > TestNG Test

  2. Observe the test fail because of missing dependencies

  3. Select the Run > Run Configurations... menu from the main menubar

  4. Select the name of the test class under the TestNG category

  5. Select the Classpath tab

  6. Select User Entries in the tree

  7. Click the Advanced... button on the right

  8. Select Add Folders and click the OK button

  9. Select the weld-jboss-tck-runner/src/test/debug-resources folder

  10. Click the OK button on the Folder Selection dialog window

  11. Click on the weld-jboss-tck-runner entry

  12. Move the weld-jboss-tck-runner to the first entry using the Up button

  13. Click the Run button on the Run Configurations dialog window

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).

You can simply right click and select Run As > TestNG Test for all subsequent runs for the reason cited earlier, the run configuration for a class is retained indefinitely.

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:

  1. Right click on the jsr299-tck-impl project

  2. Select Build Path > Configure Build Path...

  3. Click on the Libraries tab

  4. Click the Add Class Folder... button on the right

  5. Check the weld-jboss-tck-runner/src/test/debug-resources folder

  6. Click the OK button on the Class Folder Selection dialog window

  7. Click the OK button on the Java Build Path window

Now you don't have to do any special configuration per test class.

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.

You have now mastered running the CDI TCK against Weld 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.