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 ESB 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 extensions and customizations
-
Functional testing of your 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 transports 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 facilitate testing of both your Mule system configuration as well as custom modules and transports. For details, see Functional Testing.
Additionally, the Mule test JAR file contains abstract test cases that enable unit testing of your simple extensions (for example, AbstractTransformerTestCase and AbstractOutboundRouterTestCase) as well as your custom modules and transports (for example, AbstractConnectorTestCase, AbstractReceiverTestCase, AbstractDispatcherTestCase, and AbstractEndpointTestCase). For details, see Unit Testing.
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. The Mule Profiler Pack can identify memory leaks in your customizations.
Continuous Integration Testing
You can take advantage of continuous integration testing to improve project reliability. 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), 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.
See Also
-
Want more options for testing your Mule applications? Try MUnit, the Mule testing framework.