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.
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.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.
AbstractOutboundRouterTestCase) as well as your custom modules and transports (e.g.
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.
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.
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].
Want more options for testing your Mule applications? Try MUnit, MuleSoft’s application testing framework.