How to unit test production routes in Apache Camel

问题:

Let's say I have my routes created in separate RouteBuilder class. It looks like:

• grab message from JMS queue
• do some transformation, validation etc
• depending on validation results forward to specific JMS queue and save something in DB

I'd like to unit test this route with no JMS broker and no DB. I know I can mock my Processor implementations but that's not enough. I don't want to change this route (let's suppose I got that class in jar file). As far as I know from Camel in Action (sec. 6.2.6), to be able to use mocks of endpoints and other stuff I need to change my route endpoint definitions (in book's example this is change of "mina:tcp://miranda" to "mock:miranda" etc).

Is it possible to test the flow in complete isolation without changing route definitions? If I got my RouteBuilder as a separate class, am I forced to somehow "copy" route definition and change it manually? Isn't it testing the wrong thing?

I'm quite new to Camel and for me it'd be really cool to be able to have isolated unit test while deveoping routes. Just to be able to change something, run small test, observe result and so on.

回答1:

Assuming the RouteBuilder class has hardcoded endpoints then its a bit tougher to test. However if the RouteBuilder using the property placeholder for endpoint uris, then you often will be able to use a different set of endpoint uris for unit tests. As explained in chapter 6 of the Camel book.

If they are hardcoded then you can use the advice with feature in your unit test as shown here: http://camel.apache.org/advicewith.html

In Camel 2.7 we made it possible to manipulate the route much easier, so you can remove parts, replace parts, etc. Thats the weaving stuff that link talks about.

For example to simulate sending a message to a database endpoint, you can use that above and replace the to with another where you send it to a mock instead.

In previous releases you can use the interceptSendToEndpoint trick, which is also covered in the Camel book (section 6.3.3)

Oh you can also replace components with mock component as shown on page 169. Now in Camel 2.8 onwards the mock component will no longer complain about uri parameters it doesnt know. That means its much easier to replace components with mocks on a per component level.

回答2:

I have

   <bean id="properties" class="org.apache.camel.component.properties.PropertiesComponent">
        <property name="location" value="classpath:shop.properties"/>
    </bean>

    <route>
        <from uri="direct://stock"/>
        <to uri="{{stock.out}}"/>
    </route>

in my spring file and then in the shop.properties on the test class path i have a stock.out=xxxx which is replaced at runtime so i can have to different routes one for runtime and one for test

theres a better example in 6.1.6 unit testing in multiple environments

回答3:

While you can use intercepts and advice to swap out endpoints as per Claus Ibsen's answer, I think that it is far better to allow your routes to accept Endpoint instances so that your tests aren't coupled to your production endpoint URIs.

For example, say you have a RouteBuilder that looks something like

public class MyRoute extends RouteBuilder {
    @Override
    public void configure() throws Exception {
        from("http://someapi/someresource")
        .process(exchange -> {
            // Do stuff with exchange
        })
        .to("activemq:somequeue");
    }
}

You can make it possible to inject endpoints like so:

public class MyRoute extends RouteBuilder {
    private Endpoint in;
    private Endpoint out;

    // This is the constructor your production code can call
    public MyRoute(CamelContext context) {
        this.in = context.getEndpoint("http://someapi/someresource");
        this.out = context.getEndpoint("activemq:somequeue");
    }

    // This is the constructor your test can call, although it would be fine
    // to use in production too
    public MyRoute(Endpoint in, Endpoint out) {
        this.in = in;
        this.out = out;
    }

    @Override
    public void configure() throws Exception {
        from(this.in)
        .process(exchange -> {
            // Do stuff with exchange
        })
        .to(this.out);
    }
}

Which can then be tested like this:

public class MyRouteTest {
    private Endpoint in;
    private MockEndpoint out;
    private ProducerTemplate producer;

    @Before
    public void setup() {
        CamelContext context = new DefaultCamelContext();

        this.in = context.getEndpoint("direct:in");
        this.out = context.getEndpoint("mock:direct:out", MockEndpoint.class);
        this.producer = context.createProducerTemplate();
        this.producer.setDefaultEndpoint(this.in);

        RouteBuilder myRoute = new MyRoute(this.in, this.out);
        context.addRoutes(myRoute);

        context.start();
    }

    @Test
    public void test() throws Exception {
        this.producer.sendBody("Hello, world!");
        this.out.expectedMessageCount(1);
        this.out.assertIsSatisfied();
    }
} 

This has the following advantages:

• your test is very simple and easy to understand, and doesn't even need to extend CamelTestSupport or other helper classes
• the CamelContext is created by hand so you can be sure that only the route under test is created
• the test doesn't care about the production route URIs
• you still have the convenience of hard-coding the endpoint URIs into the route class if you want