To be able to do anything useful, an ESB must be configured with all sorts of parameters, from endpoint connection URIs to message transformation scripts to content-based routing definitions. Moreover, ESBs like Mule can host custom components, which will process messages and perform user-specific actions on them.

Deploying a new version of an ESB configuration raises the question of whether it will break anything. How can we build confidence that everything will be just fine? If unit testing did it for standard software development, what can it do in the realm of the ESB? Since ESBs are becoming increasingly familiar in corporate IT, getting concrete answers is of interest to more and more people.

This article details the testing strategies I employ for Mule ESB-driven projects, which I think contain elements that could be generalized to other platforms. I am certain that readers will have strategies of their own and I welcome their comments. I am also convinced that ESB vendors have their own approaches, sometimes generic, often proprietary, and that they are worth following if you use their tool. This article does not cover the subject of SOA testing strategies, which is already thoroughly discussed in the industry.

Level One: Unit Testing - Components and Transformers
Whether they are compiled or scripted, components can easily be unit tested. Provided they have been correctly initialized, unit testing them amounts to receiving an expected response for a known input. Correctly initializing a component consists of calling its lifecycle methods, if any, for compiled ones or establishing the correct environment context for scripted ones. Some components are more complex in the sense that they can be aware of the event context in which they process a message payload or need to connect to other end points. Mule's ESB functional test library (mule-tests-functional-xyz.jar) offers a variety of helpers, mostly in the form of subclasses of JUnit TestCase to establish test event context or temporary end points, which let us test this kind of component thoroughly. For example, here is an example for testing an event-aware component:

import org.mule.impl.RequestContext;
import org.mule.tck.AbstractMuleTestCase;
public class EventAwareComponentTestCase extends AbstractMuleTestCase {
protected static final String TEST_PAYLOAD = "test.foo.payload";
public EventAwareComponentTestCase() {
super();
}
@Override
protected void doSetUp() throws Exception {
RequestContext.setEvent(getTestEvent(TEST_PAYLOAD));
}
@Override
protected void doTearDown() throws Exception {
RequestContext.setEvent(null);
}
}

Transformers are very similar to components as far as testing is concerned. For the ones that are unaware of their ESB context, unit testing is straightforward; for others, Mule testing tools will come in handy. Note that at this level, it is the transformer that is tested and not how well its configuration makes the expected transformation on a particular message (this is discussed later).