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

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.