Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

You can use CDI for IoC and the Camel testing endpoints like DataSetMockTest and testing API like AdviceWith and NotifyBuilder to create sophisticated integration/unit tests that are easy to run and debug inside your IDE.

There are two a number of supported approaches for testing with CDI in Camel:

NameTesting Frameworks SupportedDescription
Camel CDI Test
  • JUnit 4

Available as of Camel 2.17

The Camel CDI test module (camel-test-cdi) provides a JUnit runner that bootstraps a test environment using CDI so that you don't have to be familiar with any CDI testing frameworks and can concentrate on the testing logic of your Camel CDI applications.

Arquillian
  • JUnit 4
  • TestNG 5
Arquillian is a testing platform that handles all the plumbing of in-container testing with support for a wide range of target containers. Arquillian can be configured to run your test classes in embedded (in JVM CDI), managed (a real Web server or Java EE application server instance started in a separate process) or remote (the lifecycle of the container isn't managed by Arquillian) modes. You have to create the System Under Test (SUT) in your test classes using ShrinkWrap Descriptorsdescriptors. The benefit is that you have a very fine-grained control over the application configuration that you want to test. The downside is more code and more complex classpath / class loading structure.
PAX Exam
  • JUnit 4
  • TestNG 6
PAX Exam lets you test your Camel applications in OSGi, Java EE or standalone CDI containers with the ability to finely configured configure your System Under Test (SUT),Similarly similarly to Arquillian. You can use it to test your Camel CDI applications that target OSGi environments like Karaf with PAX CDI, but you can use it as well to test your Camel CDI applications in standalone CDI containers, Web containers and Java EE containers.

Anchor
CamelCDITest
CamelCDITest
Camel CDI Test

With this approach, your test classes use the JUnit runner provided in Camel CDI test. This runner manages the lifecycle of a standalone CDI container and automatically assemble and deploy the System Under Test (SUT) based on the classpath into the container.

...

With this approach, you use the JUnit runner or TestNG support provided by Arquillian to delegate the bootstrap of the CDI container. You need to declare a @Deployment method to create your application configuration to be deployed in the container using ShrinkWrap Descriptorsdescriptors, e.g.:

Code Block
languagejava
@RunWith(Arquillian.class)
public class CamelCdiJavaSeTest {

    @Deployment
    public static Archive deployment() {
        return ShrinkWrap.create(JavaArchive.class)
            // Camel CDI
            .addPackage(CdiCamelExtension.class.getPackage())
            // Test classes
            .addPackage(Application.class.getPackage())
            // Bean archive deployment descriptor
            .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
    }
 
    @Inject
    CamelContext context;

    @Test
    public void test() {
        assertThat("Camel context status is incorrect!",
            context.getStatus(),
            is(equalTo(ServiceStatus.Started)));
    }
}

Using ShrinkWarp Descriptors, you have a complete control over the configuration and kind of Camel CDI applications you want to test. For example, to test a Camel CDI application that uses the Camel REST DSL configured with the Servlet component, you need to create a Web archive, e.g.In that example, you can use any Java SE Arquillian embedded container adapter, like the Weld embedded container adapter e.g. with Maven you need that complete set of dependencies:

Code Block
languagejavaxml
<dependencies>
@RunWith(Arquillian.class)
public class CamelCdiWebTest {

    @Deployment<dependency>
    public static Archive<?> createTestArchive() { <groupId>org.jboss.arquillian.junit</groupId>
        return ShrinkWrap.create(WebArchive.class)<artifactId>arquillian-junit-container</artifactId>
      <scope>test</scope>
      .addClass(Application.class)</dependency>

    <dependency>
        .addAsWebInfResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml"))<groupId>org.jboss.shrinkwrap.descriptors</groupId>
      <artifactId>shrinkwrap-descriptors-depchain</artifactId>
      .setWebXML(Paths.get("src/main/webapp/WEB-INF/web.xml").toFile());<type>pom</type>
      <scope>test</scope>
    </dependency>

    }<dependency>

    @Test
  <groupId>org.jboss.arquillian.container</groupId>
  @RunAsClient
    public void test(@ArquillianResource URL url) throws Exception {<artifactId>arquillian-weld-se-embedded-1.1</artifactId>
      <scope>test</scope>
    </dependency>

    <dependency>
    assertThat(IOHelper.loadText(new URL(url, "camel/rest/hello").openStream()), <groupId>org.jboss.weld</groupId>
      <artifactId>weld-core</artifactId>
      is(equalTo("Hello World!\n")));
    }
}

PAX Exam

 <scope>test</scope>
    </dependency>

</dependencies>

Using ShrinkWarp Descriptors, you have a complete control over the configuration and kind of Camel CDI applications you want to test. For example, to test a Camel CDI application that uses the Camel REST DSL configured with the Servlet component, you need to create a Web archive, e.g.:

Code Block
languagejava
@RunWith(Arquillian.class)
public class CamelCdiWebTest {

    @Deployment
    public static Archive<?> createTestArchive() {
        return ShrinkWrap.create(WebArchive.class)
            .addClass(Application.class)
            .addAsWebInfResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml"))
            .setWebXML(Paths.get("src/main/webapp/WEB-INF/web.xml").toFile());
    }

    @Test
    @RunAsClient
    public void test(@ArquillianResource URL url) throws Exception {
        assertThat(IOHelper.loadText(new URL(url, "camel/rest/hello").openStream()),
            is(equalTo("Hello World!\n")));
    }
}

In the example above, you can use any Arquillian Web container adapter, like the Jetty embedded container adapter e.g. with Maven you need the complete following set of dependencies:

Code Block
languagexml
</dependencies>
 
  <dependency>
    <groupId>org.jboss.arquillian.junit</groupId>
    <artifactId>arquillian-junit-container</artifactId>
    <scope>test</scope>
  </dependency>

  <dependency>
    <groupId>org.jboss.arquillian.testenricher</groupId>
    <artifactId>arquillian-testenricher-resource</artifactId>
  </dependency>

  <dependency>
    <groupId>org.jboss.shrinkwrap.descriptors</groupId>
    <artifactId>shrinkwrap-descriptors-depchain</artifactId>
    <type>pom</type>
    <scope>test</scope>
  </dependency>

  <dependency>
    <groupId>org.jboss.weld.servlet</groupId>
    <artifactId>weld-servlet</artifactId>
    <scope>test</scope>
  </dependency>
 
  <dependency>
    <groupId>org.eclipse.jetty</groupId>
    <artifactId>jetty-webapp</artifactId>
  </dependency>

  <dependency>
    <groupId>org.eclipse.jetty</groupId>
    <artifactId>jetty-annotations</artifactId>
  </dependency>

  <dependency>
    <groupId>org.jboss.arquillian.container</groupId>
    <artifactId>arquillian-jetty-embedded-9</artifactId>
  </dependency>

</dependencies>

You can see the tests in the camel-example-cdi-rest-servlet example for a complete working example of testing a Camel CDI application using the REST DSL and deployed as a WAR in Jetty.

PAX Exam

If you If your target OSGi as runtime environment for your Camel CDI applications, you can use PAX Exam to automate the deployment of your tests into an OSGi container, for example into Karaf, e.g.:

...