...
Name | Testing Frameworks Supported | Description |
---|---|---|
Camel CDI Test |
| Available as of Camel 2.17 The Camel CDI test module ( |
Arquillian |
| Arquillian is a testing platform that handles all the plumbing of in-container testing with support for a wide range a 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 Descriptors. 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. |
...
Camel CDI test provides the @Order
annotation that you can use to execute the test methods in a particular sequence, e.g.:
Code Block | ||
---|---|---|
| ||
@RunWith(CamelCdiRunner.class) public class CamelCdiRunnerTest { @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 | ||
---|---|---|
| ||
@ApplicationScoped @RunWith(CamelCdiRunner.class) public class CamelCdiRunnerTest { int counter; @Test @Order(1) public void firstTestMethod() { counter++; } @Test @Order(2) public void secondTestMethod() { assertEquals(counter, 1); } } |
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 | ||
---|---|---|
| ||
@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.:
Code Block | ||
---|---|---|
| ||
@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"))); } } |
...