Correctly Using Apache Camel’s AdviceWith in Unit Tests

We care a lot about the stuff that goes around Solr and Elasticsearch in our client’s infrastructure. One area that seems to always be being reinvented for-better-or-worse is the data ETL/data ingest path from data source X to the search engine. One tool we’ve enjoyed using for basic ETL these days is Apache Camel. Camel is an extremely feature-rich Java data integration framework for wiring up just about anything to anything else. And by anything I mean anything: file system, databases, HTTP, search engines, twitter, IRC, etc.

One area I initially struggled with with Camel was exactly how to test my code. Lets say I have defined a simple Camel route like this:

from("file:inbox")
.unmarshall(csv)  // parse as CSV
.split() // now we're operating on individual CSV lines
   .bean("customTransformation")  // do some random operation on the CSV line
   .to("solr://localhost:8983/solr/collection1/update")

Great! Now if you’ve gotten into Camel testing, you may know there’s something called “AdviceWith“. What is this interesting sounding thing? Well I think its a way of saying “take these routes and muck with them” — stub out this, intercept that and don’t forward, etc. Exactly the kind of slicing and dicing I’d like to do in my unit tests!

I definitely recommend reading up on the docs, but here’s the real step-by-step built around where you’re probably going to get stuck (cause its where I got stuck!) getting AdviceWith to work for your tests.

1. Use CamelTestSupport

Ok most importantly, we need to actually define a test that uses CamelTestSupport. CamelTestSupport automatically creates and starts our camel context for us.

 public class ItGoesToSolrTest extends CamelTestSupport {
    ...
 }

2. Specify the route builder we’re testing

In our test, we need to tell CamelTestSupport where it can access its routes:

@Override
protected RouteBuilder createRouteBuilder() {
    return new MyProductionRouteBuilder();
}

3. Specify any beans we’d like to register

Its probably the case that you’re using Java beans with Camel. If you’re using the bean integration and referring to beans by name in your camel routes, you’ll need to register those names with an instance of your class.

@Override
protected Context createJndiContext() throws Exception {
    JndiContext context = new JndiContext();
    context.bind("customTransformation", new CustomTransformation());
    return context;
}

4. Monkey with our production routes using advice with

Second we need to actually use the AdviceWithRouteBuilder before each test:

@Before
public void mockEndpoints() throws Exception {
    AdviceWithRouteBuilder mockSolr = new AdviceWithRouteBuilder() {

        @Override
        public void configure() throws Exception {
            // mock the for testing
            interceptSendToEndpoint("solr://localhost:8983/solr/collection1/update")
                .skipSendToOriginalEndpoint()
                .to("mock:catchSolrMessages");
        }
    })
    context.getRouteDefinition(1).
        .adviceWith(context, mockSolr);
 }

There’s a couple things to notice here:

1. In configure we simply snag an endpoint (in this case Solr) and then we have complete freedom to do whatever we want. In this case, we’re rewiring it to a mock endpoint we can use for testing.

2. Notice how we get a route definition by index (in this case 1) to snag the route we’re testing and that we’d like to monkey with. This is how I’ve seen it in most Camel examples, and its hard to guess how Camel is going to assign some index to your route. A better way would be to give our route definition a name:

from(“file:inbox”) .routeId(“csvToSolrRoute”) .unmarshall(csv) // parse as CSV

then we can refer to this name when retrieving our route:

 context.getRouteDefinition("csvToSolrRoute").
        .adviceWith(context, mockSolr);

5. Tell CamelTestSupport you want to manually start/stop camel

One problem you will run into with the normal tutorials is that CamelTestSupport may start routes before your mocks have taken hold. Thus your mocked routes won’t be part of what CamelTestSupport has actually started. You’ll be pulling your hair out wondering why Camel insists on attempting to forward documents to an actual Solr instance and not your test endpoint.

To take matters into your own hands, luckily CamelTestSupport comes to the rescue with a simple method you need to override to communicate your intent to manually start/stop the camel context:

@Override
public boolean isUseAdviceWith() {
    return true;
}

Then in your test, you’ll need to be sure to do:

@Test
public void foo() {
    context.start();
    // tests!
    context.stop();
}

6. Write a test!

Now you’re equipped to try out a real test!

 @Test
 public void testWithRealFile() {
    MockEndpoint mockSolr = getMockEndpoint("mock:catchSolrMessages");
    File testCsv = getTestfile();

    context.start();
    mockSolr.expectedMessageCount(1);
    FileUtils.copyFile(testCsv, "inbox");
    mockSolr.assertIsSatisfied();
    context.stop();
 }

And that’s just scratching the surface of Camel’s testing capabilities. Check out the camel docs for information on stimulating endpoints directly with the ProducerTemplate thus letting you avoid using real files — and all kinds of goodies.

Anyway, hopefully my experiences with AdviceWith can help you get it up and running in your tests! I’d love to hear about your experiences or any tips I’m missing either in the comments or [via email][5].

If you’d love to utilize Solr or Elasticsearch for search and analytics, but can’t figure out how to integrate them with your data infrastructure — contact us! Maybe there’s a camel recipe we could cook up for you that could do just the trick.