The Java code for this recipe is located in the org.camelcookbook.examples.testing.spring package. The Spring XML files are located under src/main/resources/META-INF/spring.

To use Camel's Spring test support, you need to add a dependency for the camel-test-spring library that provides the support classes for JUnit testing of Spring as well as a transitive dependency on JUnit itself.

Add the following to the dependencies section of your Maven POM:

<dependency>
  <groupId>org.apache.camel</groupId>
  <artifactId>camel-test-spring</artifactId>
  <version>${camel-version}</version>
  <scope>test</scope>
</dependency>

Consider the following route, defined in the file located in /META-INF/spring/simpleTransform-context.xml:

<route>
  <from uri="direct:in"/>
  <transform>
    <simple>Modified: ${body}</simple>
  </transform>
  <log message="Set message to ${body}"/>
  <to uri="mock:out"/>
</route>

To test this route, perform the following steps:

The CamelSpringTestSupport class is a convenience class that provides feature-parity with the CamelTestSupport class described in the Testing routes defined in Java recipe. It is responsible for performing the boilerplate work required to test Camel routes defined within Spring configuration files. At its most basic, the class will do the following:

Feature-parity with CamelTestSupport means that aside from the implementation of a different base method to the Java testing example (createApplicationContext() versus createRouteBuilder() or createRouteBuilders()), CamelSpringTestSupport allows the test methods themselves to be written in exactly the same manner as their Java DSL equivalents. Both classes provide access to the same protected variables (context and template), and honor the same test lifecycle.

The testing method described has a drawback—it requires that a Camel base class is extended. This may not be something that you would like if you want to use another class as the base for your tests. To cater for this, Camel provides what is known as the Enhanced Spring Test option.

To make use of this, your test uses the JUnit 4 Runner functionality that allows a custom class to manage the lifecycle of a test. The rewritten test class appears as follows:

@RunWith(CamelSpringJUnit4ClassRunner.class)
@ContextConfiguration({
    "/META-INF/spring/simpleTransform-context.xml"})
public class SimpleTransformSpringRunnerTest {
  //...
}

As no base class is extended, your tests no longer have access to the protected variables, or utility methods such as assertMockEndpointsSatisfied() that are provided by CamelSpringTestSupport. The workaround for this is fairly straightforward. The Camel context is injected via the @Autowired annotation, just as any other Spring object:

@Autowired
private CamelContext camelContext;

When using Enhanced Spring Tests you invoke the static MockEndpoint.assertIsSatisfied() utility method to assert that all the mock endpoints in the Camel context interface were satisfied:

@Test
public void testPayloadIsTransformed() 
    throws InterruptedException {
  mockOut.setExpectedMessageCount(1);
  mockOut.message(0).body().isEqualTo("Modified: Cheese");

  producerTemplate.sendBody("Cheese");

  MockEndpoint.assertIsSatisfied(camelContext);
}

@DirtiesContext(classMode=ClassMode.AFTER_EACH_TEST_METHOD)

Spring applications are usually broken up into multiple context files that address a particular fragment of an application each—you would generally see one file per horizontal application tier, or per vertical stack, of functionality. By making use of this approach, you can substitute alternative Spring configuration files when assembling your tests to replace portions of an application. This allows you to stub out objects used in your routes that may be difficult to wire up in a test environment.

It is usually a good idea to keep your PropertyPlaceholderConfigurer configuration in a different Spring XML file from your routes. This allows you to plug in a test version of those properties for testing.

We can use this particular mechanism to fully externalize our route endpoints, and use dependency injection to make the route more easily testable. Consider the following example:

<camelContext xmlns="http://camel.apache.org/schema/spring">
  <propertyPlaceholder id="properties" 
                       location="ref:ctx.properties"/>
  <route>
    <from uri="{{start.endpoint}}"/>
    <transform>
      <simple>Modified: ${body}</simple>
    </transform>
    <log message="Set message to ${body}"/>
    <to uri="{{end.endpoint}}"/>
  </route>
</camelContext>

By providing an alternative PropertyPlaceholderConfigurer instance–defined as a bean with an id of ctx.properties–in a test file in a test file, we can exercise the route using direct: and mock: endpoints, while referring to the actual technology endpoints in the production configuration.

The following example uses the Spring util and context namespaces for brevity to substitute test endpoints into the preceding route:

<util:properties id="ctx.properties"
                 location="classpath:spring/test.properties"/>
<context:property-placeholder properties-ref="ctx.properties" />

The test.properties file contains the test versions of the properties:

start.endpoint=direct:in
end.endpoint=mock:out

Splitting out the PropertyPlaceholderConfigurer configuration into a different file is particularly useful if the file containing your Camel context definition also contains other beans that need properties injected.

You can alternatively feed properties directly into the context through the Properties component by overriding the following method from CamelTestSupport:

@Override
protected Properties 
    useOverridePropertiesWithPropertiesComponent() {
  Properties properties = new Properties();
  properties.setProperty("start.endpoint", "direct:in");
  properties.setProperty("end.endpoint", "mock:out");
  return properties;
}

If your propertyPlaceholder refers to properties files that are not discoverable at test time, you can instruct the framework to ignore the error instead of throwing an exception that would prevent the Camel context from starting up. You do this by overriding the following method in your test:

@Override
protected Boolean ignoreMissingLocationWithPropertiesComponent() {
  return true;
}