Jitter Mule Functional Tests With Jitr

Embedding Mule in a web application allows you to tap the Servlet layer of your favorite web container, which is a good thing as you are supposedly very familiar with its behavior and tuning.

When it comes to writing functional tests for such an application, my strategy was to replace the Servlet endpoints with stock HTTP ones, a substitution that is trivial to perform thanks to the modularity of Mule configuration files: I simply loaded a slightly different set of files at functional test time than the actual file configured in my web.xml file. Since I was writing the tests as subclasses of org.mule.tck.FunctionalTestCase, all the goodness of Mule was readily available as protected methods or members.

Still, I was not very satisfied with this approach because of the discrepancy between what my functional tests were exercising (the stock HTTP transport) and what I was actually using (the Servlet transport). This discrepancy bit me badly in the past weeks with a problem only showing up with the Servlet transport.

Then came Jitr, the latest creation of international software samurai Josh Devins:

Jitr (pronounced "jitter") is a JUnit Integration Test Runner. It allows your web application integration tests to easily run against a lightweight web container in the same JVM as your tests.

It happens Jitr is extremely well fitted for functionally testing a Mule instance embedded in a web application. Here is the structure of such a Jitr powered test:

<br />@RunWith(Jitr.class)<br />public class ServicesFunctionalTest {<br /> @BaseUri<br /> private String baseUri;<br /><br /> private HttpClient httpClient;<br /><br /> private MuleContext muleContext;<br /><br /> @Before<br /> public void initializeTest() throws MuleException {<br /> httpClient = new HttpClient();<br /> muleContext = MuleServer.getMuleContext();<br /> }<br /><br /> @Test<br /> public void pingService() throws Exception {<br /> final HttpMethod method = new GetMethod(baseUri + "ping");<br /> httpClient.executeMethod(method);<br /> assertEquals("PING: OK", method.getResponseBodyAsString());<br /> }<br /><br /> ...<br />}

Thanks to the access to the MuleContext, all the internals of the loaded Mule instance are available, which means that I am free to use my asynchronous testing strategies. It's party time. really!

Note that Jitr tests are pure JUnit 4 tests, without any sub-classing needed.

Because I am still loading a slightly different configuration at test time, as I am replacing file endpoints with VM ones for easier testing, I have to load a different web.xml file. Nothing to worry, as Jitr offers the possibility to load this file from an alternate location by means of configuration only. So here is the actual beginning of my test class:
<br />@RunWith(Jitr.class)<br />@JitrConfiguration(warPath = "src/it/resources/webapp-it")<br />public class ServicesFunctionalTest {<br/>...

Jitr is a capable new tool that will complement the tool box of any developer having to run functional tests on web services.