Shared Resources and Testing

Testing is essential to all code, it’s a warranty on the expected behavior and a measure of quality. Having a large and thorough test suite increases the confidence we have on a system. That’s why Mule offers a number of options for testing, like our Functional Test Framework or MUnit, a good example of the former being FunctionalTestCase.
By extending from this class we can create our own tests around a Mule configuration XML file (or many) that will be run as an app in a Mule server. We can then run flows or use MuleClient to send requests and verify that the responses are the expected ones, for example.

Now, this works fine for most applications but when it comes to domains you also need a way to specify that configuration so that all shared resources specified there are taken into account. With DomainFunctionalTestCase you can override getDomainConfig to return the filename of the domain configuration. Adding the app’s config files is a bit different since the idea behind this test class is to be able to have several apps running for that domain. So, to set up these apps we override getConfigResources, where we should return an array of ApplicationConfigs. An ApplicationConfig consists of an app name and it’s resources (the ones you would have returned in FunctionalTestCase’s getConfigFiles). That name is important since then from our test we’ll be able to lookup the MuleContext for that app with it. Let’s look at an example.

On our domain we’ll have a shared HTTP Request config set up to hit www.httpbin.org, which is a service to test HTTP requests and responses. Sending a request to httpbin.org/status/404, for example, will return a response with a 404 status code. So, we’ll have two apps that use it to make a request to different status codes.

Our first app will hit /200 to get that status code and set it as payload, this request being triggered by an HTTP Listener.

The second app will hit /204 instead, set that status code as payload and be triggered by a VM endpoint.

Finally, our test class looks like this:

As you can see in getResponseFromApp, the main difference with FunctionalTestCase is that we need to ask for the specific MuleContext of each app using the method getMuleContextForApp. Once we have it, we can use MuleClient to send data to the HTTP and VM entry points of each app. Then we can make sure the response payload is the one we expected. Notice we are using JUnit and Hamcrest to do so, which make assertions very easy to read. These libraries are part of the Functional Test Framework as well, which is added as a Maven dependency to the project.

You can check out the entire example here and learn more about Shared Resources here on our docs site.