I've got a series of "pipelined" components that all communicate through ActiveMQ message queues. Each component uses Camel to treat each of these queues as an Endpoint. Each component uses the same basic pattern:
Where each component consumes messages off of an input queue, processes the message(s), and then places 1+ messages on an outbound/output queue. The "output" queue then becomes the "input" queue for the next component in the chain. Pretty basic.
I am now trying to roll up my sleeves and provide unit testing for each component using the MockEndpoints
provided by Camel's test API. I have been pouring over the javadocs and the few examples on Camel's website, but am having difficulty connecting all the dots.
It seems to me that, for each component, a portion of my unit testing is going to want to accomplish the following three things:
I believe I need to create MockEndpoints
for each queue like so:
@EndpointInject(uri = "mock:inputQueue")
protected MockEndpoint intputQueue;
@EndpointInject(uri = "mock:outputQueue")
protected MockEndpoint outputQueue;
So now, in my JUnit test methods, I can set up expectations and interact with these endpoints:
@Test
public final void processMethodShouldSendToOutputQueue()
{
Component comp = new Component();
comp.process();
outputQueue.assertIsSatisfied();
}
I'm just not understanding how to wire everything up correctly:
comp
to the inputQueue
and outputQueue
MockEndpoints?MockEndpoint
, how do I set up expectations so that assertIsSatisfied()
checks that a message is present inside a particular queue, or that a particular queue contains messages?A Mock endpoint which provides a literate, fluent API for testing routes using a JMock style API. The mock endpoint have two set of methods. expectedXXX or expectsXXX - To set pre conditions, before the test is executed. assertXXX - To assert assertions, after the test has been executed.
Mocking existing endpoints with XML DSL The solution is to create a new XML file used by the unit test and then include the intended XML file which has the route you want to test. Then in your unit test you load the new XML file ( test-camel-route. xml ) instead of camel-route.
The returned value from add is the route id of the new route that was added. However null is returned if the route is not yet created and added, which can happen if CamelContext is not started yet. If no route id is provided, then Camel will auto assign a route id.
Adam, there are several ways to do this.
For POJO components, blackbox test them separately from any Camel context/routing to focus on business logic.
If you want to do end-to-end testing of the routes, consider using one of these approaches to validate that each step in the route is satisfied.
I prefer AdviceWith because its very flexible and leverages the familiar MockEndpoints. For a complete example of this, see this unit test
In short, you will create a unit test to inject MockEndpoints into your route and then validate against them as usual...
context.getRouteDefinition("myRouteId").adviceWith(context, new AdviceWithRouteBuilder() {
@Override
public void configure() throws Exception {
// mock all endpoints
mockEndpoints();
}
});
getMockEndpoint("mock:direct:start").expectedBodiesReceived("Hello World");
template.sendBody("direct:start", "Hello World");
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With