This time, I’ll show you how a route is tested by using mock producers and consumers and setting up the expectations. As I always remind the team, this is unit testing, not integration testing. At this point, we need to trust that the Camel team has properly tested all it’s components. What we want to do is check that 1) our route is routing messages to the proper endpoints, and 2) our enrichers or filters are kicking in properly.

To better understand the rest of this post, reading through this might be usefull.

Route Builder modifications

In the previous example, I had hard coded all route and processor information directly into the RouteBuilder implementation.

Obviously, this won’t cut it if we want to test. So the first thing we want to do is externalize the routeconfiguration information to a class (backed by an interface. You’ll se why later).

class MyRouteBuilder extends RouteBuilder {

private IRouteBuilderConiguration config;

@Override
public void configure() throws Exception {
errorHandler(
deadLetterChannel(config.getDlqEndpointUrl()).
delay(config.getErrorHandlerDelay()).
maximumRedeliveries(config.getErrorHandlerRetries())
);

from(config.getSourceEndpointUrl()).
choice().
   when(config.getMessageFilter()).
     process(config.getMessageEnricher()).to(config.getMessageEndpointUrl()).
   otherwise().to(config.getErrorEndpointUrl());
}

}

What’s missing here is a concrete implementation of the IRouteBuilderConfiguration interface. It would look something like:

public class MyRouteBuilderConfiguration implements IRouteBuilderConfiguration {
    public String getMessageEndpointUrl() {
        return ....
    }
    ....
}

I used spring to inject the configuration into the builder, but you can use whatever you want.

<bean id="myRouteBuilder" class="default.MyRouteBuilder">
<property name="configuration">
  <bean class="default.MyRouteBuilderConfiguration">
    <property name="messageFilter" ref="myFilter"/>
    <property name="messageEnricher" ref="myEnricher"/>
  </bean>
</property>
</bean>

Test class

Once that’s done, then it’s simply a case of following what’s in the Camel testing example page with a few variations.

• Overide the createRouteBuilder() method, but make sure to send back your own implementation
• Inject a different IRouteBuilderConfiguration implementation which uses mock and direct endpoints.

For example:

public class TestMessageRouter extends CamelTestSupport {
   private static final String SOURCE_COMPONENT_URL = "direct:start";
   private static final String DLQ_COMPONENT_URL = "mock:dlq";
   private static final String INVALID_COMPONENT_URL = "mock:invalid";
   private static final String ENDPOINT_URL = "mock:endpoint";

   @EndpointInject(uri = DLQ_COMPONENT_URL)
   protected MockEndpoint dlqEndpoint;

   @EndpointInject(uri = INVALID_COMPONENT_URL)
   protected MockEndpoint invalidEndpoint;

   @EndpointInject(uri = ENDPOINT_URL)
   protected MockEndpoint endpoint;

   @Produce(uri= SOURCE_COMPONENT_URL)
   protected ProducerTemplate producerTemplate;

   public void testMessageOk() throws Exception {
     producerTemplate.sendBodyAndHeaders("a", getValidHeaders());

     invalidEndpoint.expectedMessageCount(0);
     dlqEndpoint.expectedMessageCount(0);
     endpoint.expectedMessageCount(1);

     dlqEndpoint.assertIsSatisfied();
     invalidEndpoint.assertIsSatisfied();
     endpoint.assertIsSatisfied();

     Message inMessage = endpoint.getReceivedExchanges().get(0).getIn();
     Assert.assertEquals("a", inMessage.getBody());
  }

  public void testWithInvalidBodyType() throws Exception {
     Map<String, Object> headers =createValidHeaders();
     producerTemplate.sendBodyAndHeaders(Integer.valueOf(1), headers);

     invalidEndpoint.expectedMessageCount(1);
     endpoint.expectedMessageCount(0);
     dlqEndpoint.expectedMessageCount(0);

     dlqEndpoint.assertIsSatisfied();
     invalidEndpoint.assertIsSatisfied();
     endpoint.assertIsSatisfied();
  }

  @Override
  protected RouteBuilder createRouteBuilder() throws Exception {
     MyRouteBuilder builder = new MyRouteBuilder();
     builder.setConfiguration(new TestRunnerRouteConfiguration());
     return builder;
  }

  class TestRunnerRouteConfiguration implements IRouteBuilderConfiguration {
     public Endpoint getMessageEndpoint() {
        return endpoint;
     }
     public String getDLQCompomentUrl() {
        return DLQ_COMPONENT_URL;
     }
     public String getInvalidMessageComponentUrl() {
       return INVALID_COMPONENT_URL;
     }
     public String getSourceComponentUrl() {
       return SOURCE_COMPONENT_URL;
     }
      ....
  }
}

The example isn’t complete, but it does give a good idea of what can be done. The learning curve isn’t extremely steep with Camel, but it’s there and you most likely won’t pickup all the concepts immediately. We’re not talking weeks and days, just a few hours.

I guess that covers it for now. I’ll be looking to setup a Component that can publish to Tumblr, just as an excersise, so if I get around to that, I’ll post the results here.

1. Listen on a queue for new messages
2. Validate that the message is properly formed (has a body and has the proper headers)
3. Save the content to a file (file name is in one of the headers)

Spring configuration

<bean id="myRouteBuilder" class="default.MyRouteBuilder"/>
    <bean id="myFilter" class="default.MyMessageFilter"/>
    <bean id="myEnricher" class="default.MyMessageEnricher"/>

    <camel:camelContext id="myCamelContext">
    <camel:routeBuilder ref="myRouteBuilder"/>
    </camel:camelContext>

    <bean id="jms" class="org.apache.camel.component.jms.JmsComponent">
        <property name="connectionFactory">
        <bean class="org.apache.activemq.ActiveMQConnectionFactory">
             <property name="brokerURL" value="tcp://localhost:61616"/>
        </bean>
    </property>
</bean>

The important bean here is the camelContext bean. The RouteBuilder refered to will be initialized (by calling up the configure() method on it) when the spring container gets initialized.

The ‘jms’ bean is used to configure the JMS component which can be refered to by name inside the route builder.

The 2 other beans (myEnricher and myFilter) are simply used by the route builder. A spring bean lookup is used to get a handle on these from the router.

1 gotcha: My ide (Eclipse) was giving me a lot of greif over the suggested namespace setup. Save yourself some trouble, and save the camel-spring.xsd offline  and change your namesapce declaration to something like:

<beans xmlns:camel="http://camel.apache.org/schema/spring"
xsi:schemaLocation="
http://camel.apache.org/schema/spring classpath:META-INF/camel-spring.xsd">

The RouteBuilder

This is where you build the Came routing for any messages. In this case, remember that we want to route incoming queue messages to a file (1 file per message). Ideally, any messages we can’t deal with and where there is an error in processing the message would be put into a DLQ, and any invalid messages would be put onto another queue.

public class MyRouteBuilder extends RouteBuilder implements ApplicationContextAware {
private ApplicationContext context;

@Override
public void configure() throws Exception {
    Predicate messageFilter = (Predicate) context.getBean("myFilter");
    Processor contentEnricher = (Processor) context.getBean("myEnricher");

    errorHandler(
       deadLetterChannel("jms:queue:my.dlq").
       delay(2000).
       maximumRedeliveries(5)
    );

    from("jms:queue:my.queue").
    choice().when(messageFilter).process(contentEnricher).to("file://var/tmp").
    otherwise().to("jms:queue:my.queue.invalid");
}

Explanation:

• The first section is a simple error handler that will force a message to a DLQ in the event of an exception. A lot more can be done, but this is all I needed
• Second we define the source compoment: “jms:” refers to the “jms” bean in the spring containter. Had we named that bean “activemqconnection” we would have used “activemqconnection:queue:my.queue” instead.
• We then apply a filter (implements Predicate) to determine if our message is valid (in my case, I check for specific header values). If the Predicate returns false, then we route the message to another queue.
• If the predicate passes, the message is stored in the /var/tmp directory. Specifically, for the Camel File component, the myEnricher bean takes care of setting a special header called CamelFileName which tells the component which name to give the saved file. Had that header not been present, the file would have been saved with a defaulting mechanism. An alternative would have been to use the ?fileName option in the component url (file://var/tmp?fileName=xxxxxx). See the docs for the File2 compoment.

Other classes

This isn’t super interesting, but it gives an idea how simple it is to setup a content enricher (which is really jsut a process) and a filter (Predicate)

Enricher

A note: This could have been done using the Camel DSL language, but I prefered to bring it out.

public class MyMessageEnricher implements Processor {
    private static final Logger logger = LogManager.getLogger(MyMessageEnricher.class);

    public void process(Exchange exchange) throws Exception {
       if (logger.isTraceEnabled()) {
            logger.trace("Enriching received message");
       }

    String fileName = (String) exchange.getIn().getHeader("fileName");
    exchange.getIn().setHeader(Exchange.FILE_NAME, fileName);

    if (logger.isTraceEnabled()) {
        logger.trace("Enriched content header: " + exchange.getIn().getHeader(Exchange.FILE_NAME).toString());
    }
  }
}

Filter

(This also could have been implemented using the DSL)

public class MyMessageFilter implements Predicate {
    private static final Logger logger = LogManager.getLogger(MyMessageFilter.class);

    public boolean matches(Exchange exchange) {
        if (logger.isTraceEnabled()) {
           logger.trace("Excecuting message filter");
        }

       Message in = exchange.getIn();
          for (String header : MyMessageHeaderKeys.MANDATORY_HEADERS) {
             if (in.getHeader(header) == null) {
                logger.warn("Filtering out message because of missing header: " + header);
                return false;
             }
          }

          if (in.getBody() == null) {
             logger.warn("Filtering out message because there is no content");
             return false;
          }

          if (logger.isTraceEnabled()) {
              logger.trace("Message was found to be valid. Continuing route");
          }
          return true;
      }
}

Next post, I’ll explain what brings all this together. The test cases.

The pain he describes in the article, I’m currently going through right now. Is FP, or a combination of OO and FP the solution, we’ll see.

We’ve led ourselves down the wrong path. Or, to be more precise, we followed a single, very good path, but we didn’t know when to take a different path.

But, really; it’s friggin slow. Prohibitively slow. Painfully slow.

The test

There’s nothing magic in all this code. It’s only an interface where the contracts are defined, a bogus implementation and a test class containing two test methods. The first method uses nothing at all (straight objects with no contracts), and the second method uses the full burito.

First thing was the interface

public interface IPersonManager {
   @Precondition( condition = "arg1 > 0" )
   @Postcondition(condition="not empty return and return.id > 0")
   public Person getPerson(int id);

   @Postcondition(condition="not empty return")
   public List<Person> getAll();

   @Precondition(bindArgs="arg1=person", condition = "not empty person and person.id < 1")
   @Postcondition(condition="not empty return and return.id > 0")
   public Person insert(Person person);

   @Precondition(bindArgs="arg1=person", condition = "not empty person and person.id > 0")
   @Postcondition(condition="not empty return and return.id > 0")
   public Person update(Person person);

   @Precondition(bindArgs="arg1=person", condition = "not empty person and person.id > 0")
   public void delete(Person person);
}

And a simple bogus implementation

public class PersonManagerImpl implements IPersonManager {
   public void delete(Person person) {
   }

   public List<Person> getAll() {
      List<Person> list = new ArrayList<Person>();
      list.add(new Person());
      return list;
   }

   public Person getPerson(int id) {
      Person p = new Person();
      p.setId(id);
      p.setFirstName("Mike");
      p.setLastName("McLean");
      return p;
   }

   public Person insert(Person person) {
      Person p = new Person();
      p.setId(3);
      p.setFirstName("Mike");
      p.setLastName("McLean");
      return p;
   }

   public Person update(Person person) {
      return person;
   }
}

The spring configuration

And finally the test class:

@Test
	public void testWithNoContracts() throws Exception {
		IPersonManager manager = new PersonManagerImpl();

		long start = System.currentTimeMillis();
		loopAFewTimes(manager);
		long end = System.currentTimeMillis();

		System.out.println("No spring, no contracts: " + ((end - start) / 1000) + " seconds and " + (end - start)  + " millis.");
	}

	@Test
	public void testWithContracts() throws Exception {
		ApplicationContext context = new ClassPathXmlApplicationContext("spring-context.xml");
		IPersonManager manager = (IPersonManager)  context.getBean("personManager");

		long start = System.currentTimeMillis();
		loopAFewTimes(manager);
		long end = System.currentTimeMillis();

		System.out.println("Full enchilada: " + ((end - start) / 1000) + " seconds and " + (end - start)  + " millis.");
	}

	public void loopAFewTimes(IPersonManager manager) {
		for (int x = 0; x < 10000; x++) {
			manager.getPerson(1);
			manager.getAll();

			Person personInsert = new Person();
			personInsert.setId(0);

			manager.insert(personInsert);

			Person personUpdate = new Person();
			personUpdate.setId(2);
			manager.update(personUpdate);

			manager.delete(personUpdate);
		}
	}

The results

No spring, no contracts: 0 seconds or 14 millis.
Full enchilada: 24 seconds or 24792 millis.

Now, I understand that this is not scientific, bordering on stupid and unprofessional, but still. Across 10000 loops ....! Nuff said.

I'd seriously have to re-consider using this in anything that has any need for performance. I might consider it for a low-traffic data entry site, but nothing much more. I haven't tried other implementations, so this might not be fair towards the whole DBC community.

The biggest concerns were:

1) Binds you to Spring (if you use SpringContacts):

No big deal here. We’re already fully invested into Spring.  Either way, I don’t beleive in complete de-coupling of technology. If you’re using a technology and investing time and man-power into it, you had better make the most of it. I reject the idea that putting Spring specific annotations in your code is bad practice (in my current environment at least)

2) Need to learn a new technology/language

Again, I have a lot of trouble with this. Do we need to always stay at the lowest denominator just to satisfy the ones who refuse to learn? I beleive that enthousiasm for something new and teams that are willing to teach and share their knowledge don’t mind these types of additions, especially if they get something out of it. Luckily, I work with that type of team (they really are friggin great!)

There’s a good discussion about that very subject here.

3) AOP + Introspection = Lowered performance

Yup. Absolutely. If this thing puts a major hit on the performance of my code, then I’d have to re-consider. In my current environment, I can’t afford a big hit to performance. But in most places, having more solid, more self-documented, more bug free code is what you should strive for. An extra millisecond here or there won’t kill anyone. Remember: “Scalability is not your problem. Getting people to give a shit is.”

I’ll try to post some benchmarks this weekend …

4) All this to avoid a few null checks

EXACTLY! If I can enforce the semantics of every class that implements an interface, then I don’t need to check for those nulls and those illegal arguments. Ever. How many times do you just do that check … just in case a new implementation doesn’t do what you expect it to. With an annotated interface defining and enforcing the state of a returned object, you have cleaner and more readable code.

What’s important here is that Design By Contract isn’t just about fancy assertions. It’s a way to enforce the semantics of an implementing class.

That being said, all the Java implementations of DBC libraries have been inactive forever. That makes me think that it may have turned out to be a big shinny and temporary toy. I’d be curious to know if anyone has used this. I’m still on the fence, but the concept is definitely winner.

(Something to read)

• Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems – Jamie Zawinski

• Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. – Rick Osborne
• The most exciting phrase to hear in science, the one that heralds new discoveries, is not ‘Eureka!’ but ‘That’s funny…’ – Isaac Asimov
• There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult

Well, I obviously couldn’t leave it at that. So the solution to a better smelling cache unit test lies below (tip: use the Statistics information that’s right there on the cache, but I hadn’t noticed)

import junit.framework.Assert;

@Test
public void testCache() throws Exception {
    ApplicationContext context = new ClassPathXmlApplicationContext("spring-context.xml");
    DataFacade dataFacade = (DataFacade) context.getBean("cacheInjectedDataFacade");

    TestCacheListener listener = new TestCacheListener();
    Cache cache = dataFacade.getCache();
    cache.getCacheEventNotificationService().registerListener(listener);

    dataFacade.getData();
    Assert.assertEquals(ListenerStatus.ELEMENT_ADDED, listener.getLastStatus());
    Assert.assertNotNull(cache.get(DataFacade.CACHE_KEY));

    listener.resetLastStatus();
    Assert.assertEquals(listener.getLastStatus(), ListenerStatus.RESET);

    dataFacade.getData();
    Assert.assertEquals(1, cache.getStatistics().getCacheHits());

    Thread.sleep(2500);
    dataFacade.getData();
    Assert.assertEquals(ListenerStatus.ELEMENT_ADDED, listener.getLastStatus());
}

Also, remember to reset your cache through cache.removeAll() between tests (through the @BeforeTest) or else your cache hits won’t jive.

Setup

We’ll start with a simple service class in which all caching manipulations are done from. The class is kept simple so as to not obfuscate what I’m really trying to show.

import net.sf.ehcache.Cache;
import net.sf.ehcache.Element;

public class DataFacade {
    private static final String CACHE_KEY = "mykey";

    private Cache cache;

    public String getData() {
        Element element = cache.get(CACHE_KEY);
        if (element != null && element.getValue() != null) {
            return (String) element.getValue();
        } else {
            String data = "lama";
            cache.put(new Element(CACHE_KEY, data));
            return data;
        }
    }

    public Cache getCache() {
        return cache;
    }

    public void setCache(Cache cache) {
        this.cache = cache;
    }
}

Spring Setup

Now, we need to write a test to ensure that the cache is being hit and expired properly. To do this, we’ll need to setup a test listener that will be injected into the Cache object used by the service class. Using spring, this is pretty easy, but we can also hand code it.

We’ll need a spring context configuration file somewhere in the classpath.

<?xml version="1.0" encoding="UTF-8"?>
<beans>
    <bean id="cacheInjectedDataFacade" class="org.mikem.DataFacade">
        <property name="cache" ref="cache"/>
    </bean>

    <bean id="cacheManager"
          class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
        <property name="configLocation" value="classpath:ehcache-config.xml"/>
    </bean>

    <bean id="cache" class="org.springframework.cache.ehcache.EhCacheFactoryBean">
        <property name="cacheManager">
            <ref local="cacheManager"/>
        </property>
        <property name="timeToIdle" value="2"/>
        <property name="timeToLive" value="2"/>
        <property name="eternal" value="false"/>
        <property name="diskPersistent" value="false"/>
        <property name="cacheName" value="org.mikem.lamacache"/>
    </bean>
</beans>

The things to watch out for here are:

• We’re not using a ehcache.xml confguration file. All config is done through spring.
• The package names should be changed to reflect where your own DataFacade is
• Notice the timeToIdel and timeToExpire properties on the cache bean. More on that later

Unit test and the cache event listener

Now we’re ready to write the unit test related code. We’ll first need an implementation of the net.sf.ehcache.event.CacheEventListener interface. That implementation should look like the following:

public class TestCacheListener implements CacheEventListener {
    public static enum ListenerStatus {
         RESET,
         DISPOSED, ELEMENT_EVICTED, ELEMENT_EXPIRED, ELEMENT_ADDED,
         ELEMENT_REMOVED, ELEMENT_UPDATED, REMOVED_ALL,
    };

    public ListenerStatus lastStatus;

    public ListenerStatus getLastStatus() {
        return this.lastStatus;
    }

    public void resetLastStatus() {
       this.lastStatus = ListenerStatus.RESET;
    }

    public void dispose() {
        this.lastStatus = ListenerStatus.DISPOSED;
    }

    public void notifyElementEvicted(Ehcache arg0, Element arg1) {
       this.lastStatus = ListenerStatus.ELEMENT_EVICTED;
    }

    public void notifyElementExpired(Ehcache arg0, Element arg1) {
        this.lastStatus = ListenerStatus.ELEMENT_EXPIRED;
    }

    public void notifyElementPut(Ehcache arg0, Element arg1) throws CacheException {
        this.lastStatus = ListenerStatus.ELEMENT_ADDED;
    }

    public void notifyElementRemoved(Ehcache arg0, Element arg1) throws CacheException {
          this.lastStatus = ListenerStatus.ELEMENT_REMOVED;
    }

    public void notifyElementUpdated(Ehcache arg0, Element arg1) throws CacheException {
         this.lastStatus = ListenerStatus.ELEMENT_UPDATED;
    }

    public void notifyRemoveAll(Ehcache arg0) {
         this.lastStatus = ListenerStatus.REMOVED_ALL;
    }
}

What this gives us is a listener class which we’ll inject into the cache. On each cache event, the last status member will be updated.

Now for the finale:

import junit.framework.Assert;
import net.sf.ehcache.Cache;

import org.junit.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

import com.stw.sandbox.TestCacheListener.ListenerStatus;

public class TestDataFacade {

@Test
public void testCache() throws Exception {
    ApplicationContext context = new ClassPathXmlApplicationContext("spring-context.xml");
    DataFacade dataFacade = (DataFacade) context.getBean("cacheInjectedDataFacade");

    TestCacheListener listener = new TestCacheListener();
    Cache cache = dataFacade.getCache();
    cache.getCacheEventNotificationService().registerListener(listener);

    dataFacade.getData();
    Assert.assertEquals(ListenerStatus.ELEMENT_ADDED, listener.getLastStatus());
    Assert.assertNotNull(cache.get(DataFacade.CACHE_KEY));

    listener.resetLastStatus();
    Assert.assertEquals(listener.getLastStatus(), ListenerStatus.RESET);

    dataFacade.getData();
    Assert.assertEquals(ListenerStatus.RESET, listener.getLastStatus());

    Thread.sleep(2500);
    dataFacade.getData();
    Assert.assertEquals(ListenerStatus.ELEMENT_ADDED, listener.getLastStatus());
}
}

Explanation:

• Lines 14 and 15 are the spring access and retrieval of the DataFacade instance
• Lines 17 through 19 take care of creating a new instance of the TestCacheListener and injecting it into the data facade instance
• Line 21 runs the method where we have some cache access going on
• Line 22: Because our last line actually put something in the cache, our cache listeners status will have changed. Here we’re making sure the status has been changed accordingly.
• Line 23: Make sure we have data in the cache (we could also check that the content is right)
• Line 25: Reset the last status on the listener
• Line 28: Fetch the data once again. At this point, the listeners last status will remain to RESET since it won’t have been put into the cache anew.
• Line 31: Because we configured our timeToIdle and timeToExpire to 2 seconds (see the spring config), we know that by sleeping 2.5 seconds, the next hit to our method will force a renewal of the cache content

Voila! Obviously, you could and should expand on this, but it’s start.

[EDIT] I’ve posted an update, mainly about how to access cache hits.

But I must admin that stuff like this (found through Raganwald) is uber-cool and useful.

You get some of this (all?) through Groovy, but it doesn’t feel as elegant.

When I first saw the post on Reddit, I found the reaction harsh (I still think the original poster meant “why use arrays instead of lists”).

As with Erlang, in Java arrays get in the way of readability. I understand arrays and the different usages, but I still prefer a List which is inifinitely more usable.