CDI TCK Community Documentation

- Prev
- Next

## Chapter 8. Running Tests in Eclipse

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.

## 8.1. Leveraging Eclipse’s plugin ecosystem

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 m2e plugin or an Eclipse project generated using the Maven 2 Eclipse plugin (maven-eclipse-plugin). Refer to Section 3.3, “Eclipse Plugins” for more information on these plugins.

## Note

In order to run the TCK tests in Eclipse you must have CDI TCK and Weld JBoss TCK runner projects imported. Get the source from GitHub repositories https://github.com/jboss/cdi-tck and https://github.com/weld/core.

With the m2e 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.

## Tip

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

## 8.2. Readying the Eclipse workspace

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

Here are the steps to establish the link:

1. Right click on the cdi-tck-impl project
2. Select Build Path > Configure Build Path…
3. Click on the Projects tab
4. Click the Add… button on the right
5. Check the TCK runner project (e.g., weld-jboss-runner-tck)
6. Click the OK button on the Required Project Selection dialog window
7. Click the OK button on the Java Build Path window

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:

1. Right click on the weld-jboss-runner-tck project
2. Select Maven
3. Uncheck Resolve dependencies from workspace projects option
4. Click the OK button on the Properties window

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 10:

    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.

## 8.3. Running a test in standalone mode

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

## Tip

If using m2e Eclipse plugin, you can activate/deactivate the profile in Maven section of project properties.

## Note

Note that all TestNG tests that are not included in integration and javaee-full test groups are considered to be standalone artifacts.

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

## Note

If the TCK complains that there is a property missing, close all the projects, open them again, and rebuild. The m2e plugin can be finicky getting everything built correctly the first time.

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.

## 8.4. Running integration tests

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.

## Note

Note that all TestNG tests that are included in integration and javaee-full test groups are considered to be integration tests and must be run in in-container mode. javaee-full TestNG test group contains tests that require full Jakarta EE platform (EAR packaging, JAX-WS, EJB timers, etc.).

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.

- PrevChapter 7. Executing the Test Suite
- Top of page
- Front page
- NextChapter 9. Debugging Tests in Eclipse