Apache Camel Testing

Question

We're using Spring for DI and Camel for routing/messaging. I've been asked to set up some (JUnit) unit tests for our various components (which all route messages to one another in a pipeline fashion).

After taking a gander at the general Camel testing doc and Camel-Spring testing doc, it seems like the preferred method of unit testing camel endpoints is through the Spring Test Context Framework using subclasses of objects like AbstractJUnit38SpringContextTests and the sorts.

I have absolutely zero experience with any of these APIs. So, although they make for interesting reading, it's tough for me to put them into context (no pun intended).

As such there are a few initial concepts I am struggling with:

For one, when is it appropriate to use a MockEndpoint, vs DataSet, vs Test?

Also, the Camel-Spring doc (link is above) provides the following example:

@ContextConfiguration
public class MyCamelTest extends AbstractJUnit38SpringContextTests {

    @Autowired
    protected CamelContext camelContext;

    @EndpointInject(uri = "mock:foo")
    protected MockEndpoint foo;

    public void testMocksAreValid() throws Exception {

        // lets add more expectations...
        MockEndpoint.assertIsSatisfied(camelContext);

        // now lets do some further assertions
        List<Exchange> list = foo.getReceivedExchanges();

        for (Exchange exchange : list) {
            Message in = exchange.getIn();
            ...
        }       
    }
}

If I'm even beginning to understand this API, then it seems like the code above it reading all the messages from a MockEndpoint named mock:foo...but I don't see where those messages are coming from (how they get to the endpoint in the first place)!

So my second question is: what are the standard practices for determining which endpoints to "stub" (mock)? For instance what if the same JMS message queue is utilized by two endpoints living inside two different JARs/WARs: one a producer and the other, a consumer? In this case, ProducerComponent (living inside producer.war) is a Camel endpoint that pushes messages to someQueue. And ConsumerComponent (living inside of consumer.war) is another Camel endpoint consuming messages off of someQueue.

How would SO organize the unit tests for both components?

Thanks in advance for any nudges in the right direction!

Answer 1

Excellent practice to thoroughly test your routes. The Camel testing and Spring testing resources you mentioned are probably the best starting point. Now, using Spring or not for testing depends also on the way you setup your routes, i.e. using the Spring XML dsl or the Java dsl. Obviously CamelSpringTestSupport (or even AbstractJUnit38SpringContextTests) may be more appropriate for the former, for the latter you may prefer just CamelTestSupport. Now to your questions:

1. When is it appropriate to use a MockEndpoint, vs DataSet, vs Test? It's not really 'versus', they all serve different roles and you would use them together, as needed. The Test is not something Camel specific, it's just regular JUnit tests. Camel offers some specializations and utilities to simplify testing (CamelTestSupport, etc). In general (not always) you would use Camel for systems integration, sorta like lightweight business processes, or workflows, taking advantage of the powerful EIPs (enterprise integration patterns) defined by Camel and the support for countless protocols and data formats. During your testing you may send messages to some endpoint, but how can you make sure that your processing is correct and the messages received are the expected ones? For that purpose, Camel provided the MockEndpoint, that you could (should during testing) use as a substitute for your target endpoint. That way you can use assertions to ensure that the messages received are the ones you expected, in the right order, timing, etc. Look at the properties component for convenient ways of substituting endpoints in different test (or production) environments. The DataSet is a convenient way to fire off or verify a series of messages.

2. What are the standard practices for determining which endpoints to "stub"? What usually works is to agree on the message formats and the pre- and post-conditions, i.e. you can test that the producer produces the desired messages independent of the consumer and you don't even have to use the same protocol (you can send the messages for instance to a MockEndpoint as mentioned above). That would give you a good degree of confidence that the Producer is doing the right thing. Similarly, you could test the consumer independently as well. Odds are that when put together everything will work, if not, something may be missing in your tests. Most of the times not everything can be unit tested and it's a good practice to have integration tests that are more similar to your production environment.

I could give you more concrete advice if you would have more specific questions. I hope this helps.

Answer 2

The testing chapter in the Camel book is very good. I just extend CamelTestSupport and I use the mock stuff to be a dummy input or output to the route (I don't worry about Spring or injecting things, etc). There is also a bunch of exotic stuff you can do by putting things (I forget what they are called) between components on a route to simulate failures and such. I highly recommend the above book, it's very clear and accurate.

For your second question, it depends I suppose on how your messages are being created. You could use a mock endpoint to either feed or consume from the queue (or both). There is a lot of good support in the mock endpoint to check messages.

The CamelTestSupport and it's superclass have a lot of useful methods for creating messages.