2. Testing :
• This section describes how to test your Mule
application.
• Introduction to Testing Mule
• Unit Testing
• Functional Testing
• Testing Strategies
• MUnit
3. 1. Introduction to Testing Mule :
• Typically, existing, bundled tests can fill many of
your testing requirements.
Thesrc/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.
4. 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
5. 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. RunJapex
benchmark tests to test individual packages.
Additionally, the Mule Profiler Packcan identify
memory leaks in your customizations.
6. Using MuleForge for Continuous
Integration Testing :
• If you host your Mule project on MuleForge, you can
take advantage of continuous integration testing.
MuleForge automatically builds hosted projects
using Bamboo, a Continuous Integration Build
Server from Atlassian. The build frequency for
source code is every 30 minutes, while the snapshot
build frequency is once per day. You can request
different frequencies for your individual project.
• For more information on hosting your project,
visit MuleForge.
7. 2. Unit Testing :
• Mule ESB 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.0.0-tests.jar for Mule version 3.0.0. All unit
tests inherit
from org.mule.tck.AbstractMuleTestCase
• These unit tests are beneficial for the following
reasons:
8. • 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.
9. 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.
10. unit tests in the Mule TCK:
Testing Component : Description :
• AbstractConnectorTestCase • Used to test the common
behavior of a connector. This
tests dispatching and sending
events using mock objects.
11. unit tests in the Mule TCK:
Testing Component : Description :
• AbstractMuleMessageFactoryT
estCase
• Provides tests for all the
standard methods defined in
theMuleMessageFactory interf
ace. Add specific tests for
converting your transport
message to a MuleMessage in
your subclass.
12. unit tests in the Mule TCK:
Testing Component : Description :
• AbstractMessageReceiverTest
Case
• Used to test the common
behavior of aMessageReceiver.
This tests receiving messages
using mock objects.
13. unit tests in the Mule TCK:
Testing Component : Description :
• AbstractComponentTestCase • This is the base class for unit tests
that test custom component
implementations. Concrete
subclasses of this base class
includeDefaultJavaComponentTest
Case,PooledJavaComponentTestCas
e,
andSimpleCallableJavaComponentT
estCase, each of which contains
methods for testing that component
type. For example,
theDefaultJavaComponentTestCasei
ncludes methods for testing the
creation, lifecycle, and disposal of a
basic Java component.
14. unit tests in the Mule TCK:
Testing Component : Description :
• 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
asStringByteArrayTransformer
sTestCase.
15. unit tests in the Mule TCK:
Testing Component : Description :
• DefaultMuleContextTestCase • Tests the creation and disposal
of the Mule context.
16. 3. Functional Testing :
• Because Mule ESB is light-weight and embeddable,
it is easy to run a Mule Server inside a test case.
Mule provides an abstract JUnit test case
calledorg.mule.tck.junit4.FunctionalTestCase that
runs Mule inside a test case and manages the
lifecycle of the server.
The org.mule.tck.functional package contains a
number of supporting classes for functionally testing
Mule code, includingFunctionalTestComponent.
These classes are described in more detail in the
following sections.
17. FunctionalTestComponent :
• The previous example of FunctionalTestCase
covers many common (synchronous) test
scenarios, where the flow responds directly to
the caller. FunctionalTestComponent can help
support richer tests, such as:
• Simulating asynchronous communication
• Returning mock data to the caller
• Common scenarios such as forced exceptions,
storing message history, appending text to
responses, and delayed responses.
18. 4. Testing Strategies :
• Building a comprehensive suite of automated tests for your Mule
project is the primary factor that will ensure its longevity: you’ll gain
the security of a safety net catching any regression or incompatible
change in your applications before they even leave your workstation.
• We’ll look at testing under three different aspects:
• *Unit testing: these tests are designed to be fast, with a very narrow
system under test. Mule is typically not run for unit tests.
*Functional testing: these tests usually involve running Mule,
though with a limited configuration, and should run fast enough to
be executed on each build.
*Integration testing: these tests exercise a full Mule application with
settings that are as close to production as possible. They are usually
slower to run and not part of the regular build
19. Unit Testing :
• In a Mule application, unit testing is limited to the code
that can be realistically exercised without the need to run
it inside Mule itself. As a rule of thumb, code that is Mule
aware (for example, code that relies on the registry), will
better be exercised with a functional test
• With this in mind, the following are good candidates for
unit testing:
• *Custom transformers
*Custom components
*Custom expression evaluators
*All the Spring beans that your Mule application will use.
Typically, these beans come as part of a dependency JAR
and are tested while being built, alleviating the need for
re-retesting them in your Mule application project
20. Functional Testing :
• Functional tests are those that most extensively
exercise your application configuration. In these
tests, you’ll have the freedom and tools for
simulating happy and unhappy paths.
• The "paths" that you will be interested to cover
include:
• *Message flows
*Rule-based routing, including validation
handling within these flows
*Error handling
21. 5. Munit :
• Munit is Beta-version Mule testing framework that allows
you to:
• mock the output of your message processors
• write tests in XML or Java
• create tests in the Anypoint Studio drag-and-drop interface
• insert spy functionality to track what happens before and after
a message processor is called
• view coverage reports in Studio
• run tests with your plugins
• access detailed Mule stacktraces that pinpoint message
processor failures
• integrate with Maven and Surefire for continuous integration
support
