Page History

CDI Testing

Testing is a crucial part of any development or integration work. In case you're using the Camel CDI integration for your applications, you have a number of options to ease testing.

...

Code Block

language	xml

<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-test-cdi</artifactId>
    <scope>test</test>scope>
    <version>x.x.x</version>
    <!-- use the same version as your Camel core version -->
</dependency>

...

Code Block

language	java

@RunWith(CamelCdiRunner.class)
public class CamelCdiRunnerTestCamelCdiTest {

    @Inject
    CamelContext context;

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

...

Code Block

language	java

@RunWith(CamelCdiRunner.class)
public class CamelCdiRunnerTestCamelCdiTest {

    @Test
    public void test(@Uri("direct:foo") ProducerTemplate producer) {
        producer.sendBody("bar");
    }
}

Camel CDI test provides the @Order annotation that you can use to execute the test methods in a particular sequence, e.g.:

Code Block

language	java

@RunWith(CamelCdiRunner.class)
public class CamelCdiRunnerTestCamelCdiTest {
 
    @Test
    @Order(1)
    public void firstTestMethod() {
    }
 
    @Test
    @Order(2)
    public void secondTestMethod() {
    }
}

One CDI container is bootstrapped for the entire execution of the test class.

Besides, the test class is deployed as a CDI bean, so that you can control how the runner instantiate the test class, either one test class instance for each test method (the default, depending on the built-in default @Dependent CDI scope), or one test class instance for the entire test class execution using the @ApplicationScoped scope, e.g.:

Code Block

language	java

@ApplicationScoped
@RunWith(CamelCdiRunner.class)
public class CamelCdiRunnerTestCamelCdiTest {
 
    int counter;

    @Test
    @Order(1)
    public void firstTestMethod() {
        counter++;
    }
 
    @Test
    @Order(2)
    public void secondTestMethod() {
        assertEquals(counter, 1);
    }
}

Arquillian

With this approachIn case you need to add additional test beans, you can use the JUnit runner or TestNG support @Beans annotation 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 descriptors, Camel CDI test. For example, if you need to add a route to your Camel context, instead of declaring a RouteBuilder bean with a nested class, you can declare a managed bean, e.g.:

Code Block

language	java

@RunWith(Arquillian.class)
public class CamelCdiJavaSeTestclass TestRoute extends RouteBuilder {

    @Deployment@Override
    public staticvoid Archive deploymentconfigure() {
        from("direct:foo").to("mock:bar");
    }
}

And add it with the @Beans annotation, e.g.:

Code Block

language	java

@RunWith(CamelCdiRunner.class)
@Beans(classes = TestRoute.class)
public class CamelCdiTest {

}

Arquillian

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 descriptors, e.g.:

Code Block

language	java

@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
        return    ShrinkWrap.addAsManifestResourcecreate(EmptyAsset.INSTANCE, "beans.xml");JavaArchive.class)
    }
 
     @Inject
   // CamelContextCamel context;
CDI
    @Test
    public void test() {
  .addPackage(CdiCamelExtension.class.getPackage())
       assertThat("Camel context status is incorrect!",     // Test classes
            context.getStatus.addPackage(Application.class.getPackage(),)
            // Bean archive  is(equalTo(ServiceStatus.Started)));
    }
}

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

language	xml

<dependencies>
deployment descriptor
            .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
    <dependency>}
 
      <groupId>org.jboss.arquillian.junit</groupId>@Inject
      <artifactId>arquillian-junit-container</artifactId>CamelContext context;

      <scope>test</scope>@Test
    </dependency>

public void test()  <dependency>{
      <groupId>org.jboss.shrinkwrap.descriptors</groupId>
  assertThat("Camel context status  <artifactId>shrinkwrap-descriptors-depchain</artifactId>is incorrect!",
      <type>pom</type>
      <scope>test</scope>context.getStatus(),
    </dependency>

    <dependency>
    is(equalTo(ServiceStatus.Started)));
    }
}

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

language	xml

<dependencies>
  <groupId>org.jboss.arquillian.container</groupId>
      <artifactId>arquillian-weld-se-embedded-1.1<<dependency>
      <groupId>org.jboss.arquillian.junit</groupId>
      <artifactId>arquillian-junit-container</artifactId>
      <scope>test</scope>
    </dependency>

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

</dependencies>
    <dependency>
      <groupId>org.jboss.arquillian.container</groupId>
      <artifactId>arquillian-weld-se-embedded-1.1</artifactId>
      <scope>test</scope>
    </dependency>

    <dependency>
      <groupId>org.jboss.weld</groupId>
      <artifactId>weld-core</artifactId>
      <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

language	java

@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

language	xml

</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>
    <scope>test</scope>
  </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>
    <scope>test</scope>
  </dependency>

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

  <dependency>
    <groupId>org.jboss.arquillian.container</groupId>
    <artifactId>arquillian-jetty-embedded-9</artifactId>
    <scope>test</scope>
  </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 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.:

Code Block

language	java

@RunWith(PaxExam.class)
@ExamReactorStrategy(PerClass.class)
public class PaxCdiOsgiTest {

    @Configuration
    public Option[] config() throws IOException {
        return options(
            // Karaf configuration
            karafDistributionConfiguration()
                .frameworkUrl(
                    maven()
                       .groupId("org.apache.karaf")
                       .artifactId("apache-karaf")
                       .versionAsInProject()
                       .type("zip"))
                .name("Apache Karaf")
                .unpackDirectory(new File("target/paxexam/unpack/")),
            // PAX CDI Weld
            features(
                maven()
                    .groupId("org.ops4j.pax.cdi")
                    .artifactId("pax-cdi-features")
                    .type("xml")
                    .classifier("features")
                    .versionAsInProject(),
                "pax-cdi-weld"),
            // Karaf Camel commands
            mavenBundle()
                .groupId("your.application.groupId")
                .artifactId("your.application.artifactId")
                .versionAsInProject()
        );
    }
 
    @Inject
    private CamelContext context;

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

You can see the tests in the camel-example-cdi-osgi example for a complete working example of testing a Camel CDI application deployed in an OSGi container using PAX Exam.

Testing Patterns

You can see the tests in the camel-example-cdi-test example for a thorough overview of the following testing patterns for Camel CDI applications.

Info
While the patterns above are illustrated using the Camel CDI test module, they should equally work with Arquillian and PAX Exam unless otherwise stated or illustrated with a specific example.

Test routes

You may want to add some Camel routes to your Camel CDI applications for testing purpose. For example to route some exchanges to a MockEndpoint instance. You can do that by declaring a RouteBuilder bean within the test class as you would normally do in your application codeUsing 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

language	java

@RunWith(ArquillianCamelCdiRunner.class)
public class CamelCdiWebTestCamelCdiTest {
 
    @Deployment
// Declare a RouteBuilder publicbean staticfor Archive<?> createTestArchive() {testing purpose
    // that is  return ShrinkWrap.create(WebArchive.class)
automatically added to the Camel context
    static class TestRoute extends RouteBuilder {

    .addClass(Application.class)
    @Override
    public void configure() {
        .addAsWebInfResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml"))from("direct:out").routeId("test").to("mock:out");
    }
 
    //    .setWebXML(Paths.get("src/main/webapp/WEB-INF/web.xml").toFile());
    }

And retrieve the MockEndpoint for further assertions
    @Test@Inject
    @RunAsClient@Uri("mock:out")
    public void test(@ArquillianResource URL url) throws Exception {
        assertThat(IOHelper.loadText(new URL(url, "camel/rest/hello").openStream()),
            is(equalTo("Hello World!\n")));
    }
}MockEndpoint mock;
}

You can find more information in auto-detecting Camel routes.

In case you prefer declaring the RouteBuilder bean in a separate class, for example to share it more easily across multiple test classes, you can use the @Beans annotation to instruct Camel CDI test to deploy that class as a CDI bean, e.g.:

Code Block

language	java

@RunWith(CamelCdiRunner.class)
@Beans(classes = TestRoute.class)
public class CamelCdiTest {

    // ...
}

Bean alternatives

You may want to replace a bean that is used in your Camel routes by another bean for testing purpose, for example to mock it or change the behaviour of the application bean.

Imagine you have the following route in your applicationIn 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

language	xml	java

public class Application {

    @ContextName("camel-test-cdi")
    static class Hello extends RouteBuilder {
</dependencies>
 
  <dependency>
    <groupId>org.jboss.arquillian.junit</groupId>
    <artifactId>arquillian-junit-container</artifactId>
    <scope>test</scope>@Override
  </dependency>

  <dependency>
    <groupId>org.jboss.arquillian.testenricher</groupId>
    <artifactId>arquillian-testenricher-resource</artifactId>public void configure() {
    <scope>test</scope>
  </dependency>

  <dependency>
    <groupId>org.jboss.shrinkwrap.descriptors</groupId>from("direct:in").bean("bean").to("direct:out");
    <artifactId>shrinkwrap-descriptors-depchain</artifactId>
    <type>pom</type>}
     <scope>test</scope>
  </dependency>}
}

And the corresponding bean:

Code Block

language	java

@Named("bean")
public class Bean {

  <dependency>
  public String process(@Body  <groupId>org.jboss.weld.servlet</groupId>String body) {
    <artifactId>weld-servlet</artifactId>
    <scope>test</scope>return body;
  </dependency>
 
  <dependency>
    <groupId>org.eclipse.jetty</groupId>
    <artifactId>jetty-webapp</artifactId>
    <scope>test</scope>
  </dependency>

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

  <dependency>
    <groupId>org.jboss.arquillian.container</groupId>
    <artifactId>arquillian-jetty-embedded-9</artifactId>
    <scope>test</scope>
  </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

}
}

Then you can replace the bean above in your tests by declaring an alternative bean, annotated with @Alternative, e.g.:

Code Block

language	java

@Alternative
@Named("bean")
public class AlternativeBean {

    public String process(@Body String body) {
        return body + " with alternative bean!";
    }
}

And you need to activate (a.k.a. select in CDI terminology) this alternative bean in your tests. If your using the CamelCdiRunner JUnit runner, you can do that with the @Beans annotation provided by the Camel CDI test module, If you 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.:

Code Block

language	java

@RunWith(PaxExamCamelCdiRunner.class)
@ExamReactorStrategy(PerClass.class)
public class PaxCdiOsgiTest {

    @Configuration
    public Option[] config() throws IOException {
        return options(
            // Karaf configuration@Beans(alternatives = AlternativeBean.class)
public class CamelCdiTest {

    @Test
    public void testAlternativeBean(@Uri("direct:in")      karafDistributionConfiguration()ProducerTemplate producer
                .frameworkUrl(
                    maven@Uri("mock:out")
 MockEndpoint mock) throws InterruptedException {
         mock.expectedMessageCount(1);
         mock.groupIdexpectedBodiesReceived("org.apache.karaftest with alternative bean!");

        producer.sendBody("test");

        MockEndpoint.assertIsSatisfied(1L,       .artifactId("apache-karaf")TimeUnit.SECONDS, mock);
    }

    static class TestRoute extends RouteBuilder {

          .versionAsInProject()@Override
        public void configure() {
            .typefrom("direct:out").routeId("ziptest").to("mock:out");
        }
        .name("Apache Karaf}
}

If you're using Arquillian as testing framework, you need to activate the alternative in your deployment method, e.g.:

Code Block

language	java

@RunWith(Arquillian.class)
public class CamelCdiTest {

")
       @Deployment
    public static Archive   .unpackDirectory(new File("target/paxexam/unpack/")),deployment() {
            // PAX CDI Weld
            features(
return ShrinkWrap.create(JavaArchive.class)
        // Camel CDI
        maven.addPackage(CdiCamelExtension.class.getPackage())
        // Test classes
          .groupIdaddPackage("orgApplication.ops4j.pax.cdi"class.getPackage())
        // Bean archive deployment descriptor
        .artifactId("pax-cdi-features")
           addAsManifestResource(
         .type("xml")
    new StringAsset(
                Descriptors.classifier("features"create(BeansDescriptor.class)
                    .versionAsInProjectgetOrCreateAlternatives(),
                "pax-cdi-weld"),
        .stereotype(MockAlternative.class.getName()).up()
     // Karaf Camel commands
            mavenBundle.exportAsString()),
                .groupId("yourbeans.application.groupIdxml")
      ;
    }

      .artifactId("your.application.artifactId")
                .versionAsInProject(//...
}

Camel context customization

You may need to customize your Camel contexts for testing purpose, for example disabling JMX management to avoid TCP port allocation conflict. You can do that by declaring a custom Camel context bean in your test class, e.g.:

Code Block

language	java

@RunWith(CamelCdiRunner.class)
public class CamelCdiTest {
 
    @Default
    @ContextName("camel-test-cdi")
        );@ApplicationScoped
    }
 
static class CustomCamelContext extends @Inject
    private CamelContext context;DefaultCamelContext {

    @Test
    public void testContextStatus() {@PostConstruct
        assertThat("Camel context statusvoid is incorrect!",customize() {
            context.getStatusdisableJMX(), equalTo(ServiceStatus.Started));
        }
}

You can see the tests in the camel-example-cdi-osgi example for a complete working example of testing a Camel CDI application deployed in an OSGi container using PAX Exam.

Testing Patterns

}
}

In that example, the custom Camel context bean declared in the test class will be used during the test execution instead of the default Camel context bean provided by the Camel CDI componentYou can see the tests in the camel-example-cdi-test example for a thorough overview of the following testing patterns for Camel CDI applications.

Routes advising with `adviceWith`

...

It is recommended to only advice routes which are not started already. To meet that requirement, you can use the CamelContextStartingEvent event by declaring an observer method in which you use adviceWith to add a mock endpoint at the end of your Camel route, e.g.:

Code Block

language	java

@RunWith(CamelCdiRunner.class)
public class CamelCdiTest {
 
    void advice(@Observes CamelContextStartingEvent event,
                @Uri("mock:test") MockEndpoint messages,
                ModelCamelContext context) throws Exception {

        context.getRouteDefinition("route")
            .adviceWith(context, new AdviceWithRouteBuilder() {
                @Override
                public void configure() {
                    weaveAddLast().to("mock:test");
                }
            });
}

Bean alternatives

Test routes

Camel context customisation

}
}

JUnit rules

Camel CDI test starts the CDI container after all the JUnit class rules have executed.

That way, you can use JUnit class rules to initialise (resp. clean-up) resources that your test classes would require during their execution before the container initialises (resp. after the container has shutdown). For example, you could use an embedded JMS broker like like ActiveMQ Artemis to to test your Camel JMS application, e.g.:

Code Block

language	java

import org.apache.activemq.artemis.jms.server.embedded.EmbeddedJMS;
 
@RunWith(CamelCdiRunner.class)
public class CamelCdiTest {
 
    @ClassRule
    public static final ExternalResource resources = new ExternalResource() {

        private final EmbeddedJMS jms = new EmbeddedJMS();

        @Override
        protected void before() throws Exception {
            jms.start();
        }
        @Override
        protected void after() throws Exception {
            jms.stop();
        }
    };
 
    @Inject
    @Uri("jms:destination")
    private ProducerTemplate producer;
 
    @Test
    public void sendMessage() {
        producer.sendBody("message");
    }
}

Another use case is to assert the behaviour of your application after it has shutdown. In that case, you can use the the Verifier rule rule, e.g.:

Code Block

language	java

import org.junit.rules.Verifier;
 
@RunWith(CamelCdiRunner.class)
public class CamelCdiTest {
 
    @ClassRule
    public static Verifier verifier = new Verifier() {
 
        @Override
        protected void verify() {
            // Executes after the CDI container has shutdown
        }
    };
}

...

Child pages

Versions Compared

Old Version 11

New Version Current

Key

CDI Testing

Arquillian

Arquillian

PAX Exam

Testing Patterns

Test routes

Bean alternatives

PAX Exam

Camel context customization

Testing Patterns

Routes advising with `adviceWith`

Bean alternatives

Test routes

Camel context customisation

JUnit rules

Child pages

Page History

Versions Compared

Old Version 11

New Version Current

Key

CDI Testing

Arquillian

Arquillian

PAX Exam

Testing Patterns

Test routes

Bean alternatives

PAX Exam

Camel context customization

Testing Patterns

Routes advising with adviceWith

Bean alternatives

Test routes

Camel context customisation

JUnit rules

Routes advising with `adviceWith`