Software As If It Matters

David Dossot

Subscribe to David Dossot: eMailAlertsEmail Alerts
Get David Dossot: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: SOA & WOA Magazine, SOA Testing

SOA & WOA: Article

ESB Testing Strategies with Mule

Will it break anything?

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).

More Stories By David Dossot

David Dossot has worked as a software engineer and architect for more than 14 years. He is a co-author of Mule in Action and is the project despot of the JCR Transport and a member of the Mule Community Committee. He is the project lead of NxBRE, an open source business rules engine for the .NET platform (selected for O'Reilly's Windows Developer Power Tools). He is also a judge for the Jolt Product Excellence Awards and has written several articles for SD Magazine. He holds a Production Systems Engineering Diploma from ESSTIN.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.