Enterprise Integration Zone is brought to you in partnership with:

Doug has been engrossed in programming since his parents first bought him an Apple IIe computer in 4th grade. Throughout his early career, Doug proved his flexibility and ingenuity in crafting solutions in a variety of environments. Doug’s most recent work has been in the telecom industry developing tools to analyze large amounts of network traffic using C++ and Python. Doug loves learning and synthesizing this knowledge into code and blog articles. Doug is a DZone MVB and is not an employee of DZone and has posted 33 posts at DZone. You can read more from them at their website. View Full User Profile

Correctly Using Apache Camel’s AdviceWith in Unit Tests

05.16.2014
| 5228 views |
  • submit to reddit

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.

Published at DZone with permission of Doug Turnbull, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)