Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (3.9)
  3. Reference
  4. Testing

  5. Unit Testing

Unit Testing

Mule provides a Test Compatibility Kit (TCK) of unit tests that you can use to test your simple extensions as well as your custom modules and transports. The unit tests are located in the -tests.jar file, such as mule-core-3.8.1-tests.jar for Mule version 3.8.1. All unit tests inherit from org.mule.tck.AbstractMuleTestCase

These unit tests are beneficial for the following reasons:

  • Components tested with a TCK test case ensure that the common behavior of the component is compatible with the Mule framework.

  • Using a TCK test case allows the developer to concentrate on writing tests for specific behavior of their component.

  • Where testing of a method in the Component API cannot be tested by the TCK test case, the test cases provides an abstract method for the test, ensuring the developer tests all areas of the component.

  • The TCK provides a default test model that is a simple set of test classes. The developer doesn’t need to worry about writing new test classes for their test cases each time.

  • The abstract test cases in the TCK use JUnit’s TestCase, so they are compatible with other test cases.

Following is a description of some of the unit tests in the Mule TCK:

Testing Component Description

AbstractMuleTestCase

A helper test case providing methods for creating test and mock object types. This is the base class for all other abstract TCK classes.

AbstractConnectorTestCase

Used to test the common behavior of a connector. This tests dispatching and sending events using mock objects.

AbstractMuleMessageFactoryTestCase

Provides tests for all the standard methods defined in the MuleMessageFactory interface. Add specific tests for converting your transport message to a MuleMessage in your subclass.

AbstractMessageReceiverTestCase

Used to test the common behavior of a MessageReceiver. This tests receiving messages using mock objects.

AbstractComponentTestCase

This is the base class for unit tests that test custom component implementations. Concrete subclasses of this base class include DefaultJavaComponentTestCase, PooledJavaComponentTestCase, and SimpleCallableJavaComponentTestCase, each of which contains methods for testing that component type. For example, the DefaultJavaComponentTestCase includes methods for testing the creation, lifecycle, and disposal of a basic Java component.

AbstractTransformerTestCase

Used to test transformers. This class defines a number of tests that ensures that the transformer works in single scenarios as well as in round trip scenarios. There are many concrete sub-classes of this abstract class that test specific types of transformers, such as StringByteArrayTransformersTestCase.

DefaultMuleContextTestCase

Tests the creation and disposal of the Mule context.

Example Testing Transports

/**
     * Functional, real world scenario.
     * In this case you should use the transport protocol independently of Mule API. For example, for HTTP you can use Apache HTTP Client.
     */

    @Test
    public void httpEndpoint() throws IOException
    {
        DefaultHttpClient client = new DefaultHttpClient();
        HttpGet httpGet = new HttpGet("http://localhost:8080/in");
        HttpResponse response = client.execute(httpGet);
    }


    /**
     * Sending a message straight to a flow MPs pipeline, skipping its message source.
     */

    @Test
    public void skippingMessageSource() throws Exception
    {
        Flow flow = (Flow) getFlowConstruct("in-flow");
        MuleEvent event = getTestEvent("message", flow);
        MuleEvent result = flow.process(event);
        assertEquals("message", result.getMessage().getPayloadAsString());
    }

Example Testing a Flow

<http:listener-config name="listener-config" host="localhost" port="8081"/>
<flow name="in-flow">
        <http:listener config-ref="listener-config" path="/" doc:name="HTTP Connector"/>
        <echo-component/>
        <vm:outbound-endpoint path="out" />
    </flow>

See Also