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

  4. Introduction to Testing Mule

Introduction to Testing Mule

Mule Runtime Engine versions 3.5, 3.6, and 3.7 reached End of Life on or before January 25, 2020. For more information, contact your Customer Success Manager to determine how you can migrate to the latest Mule version.

This page covers testing options for your Mule projects.

Typically, existing, bundled tests can fill many of your testing requirements. The src/test/ directory in every Mule Maven project incorporates both unit and functional tests. The included Maven tests project contains additional useful functional and integration tests.

Types of Testing

You can leverage the following bundled tests when configuring and customizing Mule:

  • Unit testing of your simple extension and customizations

  • Functional testing of you Mule configuration and setup

  • Functional and unit testing of your custom modules and transports

  • Integration testing of multiple modules, transports, and transformers, etc.

  • System testing of transport that connect to embedded or external services

  • Stress and performance testing

The functional test classes that Mule provides in the org.mule.tck and org.mule.tck.functional packages facilitates testing of both your Mule system configuration as well as custom modules and transports. For details, see [Functional Testing].

Additionally, the Mule JAR file contains abstract test cases that enable unit testing of your simple extensions (e.g. AbstractTransformerTestCase and AbstractOutboundRouterTestCase) as well as your custom modules and transports (e.g. AbstractConnectorTestCase, AbstractReceiverTestCase, AbstractDispatcherTestCase and AbstractEndpointTestCase).

Performance Tests

After you have ensured that your setup and configuration are correct and that your customizations work correctly, verify that your system is performing as intended. Run Japex benchmark test to test individual packages. Additionally, the Mule Profiler Pack can identify memory leaks in your customizations.

Continuous Integration Testing

You can take advantage of continuous integration testing to improve reliability in your applications. One example integration testing application is Bamboo, which automatically builds hosted projects using a Continuous Integration Build Server from Atlassian. The typical build frequency for source code is every 30 minutes, while the snapshot build frequency is once per day.

Using IDEs

You can use an integrated development environment (IDE) such as Anypoint Studio (which is based on Eclipse), and IntelliJ to rapidly develop Mule applications. For more information on Anypoint Studio, see [Anypoint Studio Essentials].

Usually, you simply attach the src.zip file that comes with the Mule distribution to the Mule JARs in your project so you can browse the source code while developing your classes. If you want to build Mule from source, see [Contribution to Mule Source Doe Using an IDE].

See Also

  • Want more options for testing your Mule applications? Try MUnit, MuleSoft’s application testing framework.