Contact Us 1-800-596-4880
  1. Homepage
  2. Anypoint Connector DevKit (3.3)
  3. Documenting Mule Extensions

  4. Testing Your Connector

Testing Your Connector

An important part of developing your Mule extensions is to write unit tests. Unit tests fall into several different categories, all covered below.

Testing the validation of input data

As your cloud service accepts data that will be sent to the cloud service it may implement consistency checks for its input. Some parameters may be optional, some must have a meaningful value for the cloud service. You should implement unit tests that specify an invalid input to each of your cloud connector’s methods and check that the proper input validation is performed.

Testing the interaction with the cloud service

The main purpose of your cloud connector is integration of a local API with a remote one. Through the local API developers can use the web service in the same way they use a local service.

The cloud connector, however, typically talks over the internet with some remote service. This means that errors in the connection with the service may occur such as timeouts or network packet loss. Your cloud connector could handle these types of errors either gracefully by retrying or simply throw an exception. Whatever type of error handling you choose, make sure you test the error handling. Often, you may need to mock out the web service you are testing against as you won’t be able to reproduce certain error conditions (e.g. timeouts, connection loss) from your side.

When you create a new project a test case skeleton is created in the project.

Testing Mule integration

When you create a new project a Mule namespacehandler class and a schema will be automatically generated from your cloud connector class. Along with the other unit tests you should also test this Mule integration. As best practice, add at least one test for each element that is generated into the Mule schema.

A test class for the namespace handler is created in the project when it is created. The test class has some helper methods and comments that give you an idea of how to get started with writing unit tests using flows in Mule configuration.

Let’s walk thru a typical test class:

package org.mule.module.movies;

import org.mule.api.MuleEvent;
import org.mule.construct.SimpleFlowConstruct;
import org.mule.tck.FunctionalTestCase;

public class MovieConnectorTest extends FunctionalTestCase
{

    @Override
    protected String getConfigResources()
    {
        return "config/movie-search.xml";
    }

    public void testSearch() throws Exception
    {
        String payload = "<movie/>";
        SimpleFlowConstruct flow = lookupFlowConstruct("search");
        MuleEvent event = getTestEvent(payload);
        MuleEvent responseEvent = flow.process(event);
    }

    private SimpleFlowConstruct lookupFlowConstruct(String name)
    {
        return (SimpleFlowConstruct) muleContext.getRegistry().lookupFlowConstruct(name);
    }

}

First of all, you will notice that it inherits from a FunctionalTestCase. This is base class for all functional tests within Mule ESB.

The getConfigResources must return a resource within the classpath that contains the XML describing the Mule configuration. It is generally located within src/main/resources.

Next is the test method itself. Let’s walk thru it line by line.

String payload = "<movie/>";

Nothing fancy here, it is just setting a variable with some payload. We do recommend that you acquire this content from a resource in your test folder.

SimpleFlowConstruct flow = lookupFlowConstruct("search");

This line will use the convenient method lookupFlowConstruct (that in turns uses Mule’s Registry) to lookup for the flow that you defined inside your XML configuration.

MuleEvent event = getTestEvent(payload);
MuleEvent responseEvent = flow.process(event);

Now, again this is pretty simple. The first line will generate a test event using the payload you specified and the second one will initiate the flow using the generated test event. Assuming that your flow calls your connector all should be good.

You can alternatively get the output payload from responseEvent and assert as needed.

The following is an example Mule configuration:

<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesoft.org/schema/mule/core"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:spring="http://www.springframework.org/schema/beans"
      xmlns:movie="http://www.mulesoft.org/schema/mule/movie"
      xsi:schemaLocation="
        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/3.1/mule.xsd
        http://www.mulesoft.org/schema/mule/movie mule-movie.xsd">

    <movie:config apiKey="ded7fc9a3f7607459664c8d4931772ea0"/>

    <flow name="search">
        <movie:search text="The Matrix"/>
    </flow>
</mule>
For more information about testing in Mule, consult Testing With Mule ESB 3.