Mule testing

1. Presented By
Sindhu VL

2. This section describes how to test your
Mule application.
Introduction to Testing Mule
Unit Testing
Functional Testing
Testing Strategies
MUnit

3. 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.  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. 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.  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. 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. 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. TESTING COMPONENT : DESCRIPTION :
 AbstractConnectorTestCase  Used to test the common
behavior of a connector.
This tests dispatching and
sending events using mock
objects.

11. TESTING COMPONENT : DESCRIPTION :
 AbstractMuleMessageFactor
yTestCase
 Provides tests for all the
standard methods defined in
theMuleMessageFactory int
erface. Add specific tests for
converting your transport
message to a MuleMessage
in your subclass.

12. TESTING COMPONENT : DESCRIPTION :
 AbstractMessageReceiverTe
stCase
 Used to test the common
behavior of
aMessageReceiver. This
tests receiving messages
using mock objects.

13. TESTING COMPONENT : DESCRIPTION :
 AbstractComponentTestCas
e
 This is the base class for unit
tests that test custom component
implementations. Concrete
subclasses of this base class
includeDefaultJavaComponentTe
stCase,PooledJavaComponentT
estCase,
andSimpleCallableJavaCompon
entTestCase, each of which
contains methods for testing that
component type. For example,
theDefaultJavaComponentTestC
aseincludes methods for testing
the creation, lifecycle, and
disposal of a basic Java
component.

14. TESTING COMPONENT : DESCRIPTION :
 AbstractTransformerTestCas
e
 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
asStringByteArrayTransform
ersTestCase.

15. TESTING COMPONENT : DESCRIPTION :
 DefaultMuleContextTestCas
e
 Tests the creation and
disposal of the Mule context.

16.  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.  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.  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.  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 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.  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

22. MUnit is a Mule application testing
framework that allows you to easily build
automated tests for your integrations and
APIs. It provides a full suite of integration
and unit test capabilities, and is fully
integrated with Maven and Surefire for
integration with your continuous
deployment environment.

23. Create your Mule test by writing Mule code
Create your Mule test by writing Java code
Disable flow inbound endpoints
Disable endpoint connectors
Mock outbound endpoints
Mock message processors

24. Create not only unit tests but also
integration tests in a local environment —
MUnit allows you to start a local
FTP/SFTP, DB server or mail server
Call the Mule client from Mule code
Assert flow exceptions
Spy any message processor
Verify message processor calls

25. Enable or disable particular tests
See assertion/error reports with Mule stack
trace
Extend the MUnit framework with plugins
Check visual coverage in Studio
Debug your tests with Studio

26. MUnit is divided among several sub
modules. From a user’s point of view there
are only two that are really important. Both
modules are compatible amongst
themselves.
The important sub modules are:
MUnit Version Mule MUnit Support
Version
1.0.x 3.6.x, 3.7.x
1.1.x 3.6.x, 3.7.x

27. The Mule MUnit Support module is meant
to follow Mule ESB releases:
Mule MUnit Support
Version
Mule ESB Version
3.6.x 3.6.0 to 3.6.x
3.7.x 3.7.0 to 3.7.x

28. MUnit is fully integrated with Anypoint
Studio, allowing you to create, design and
run MUnit tests just like you would Mule
applications. You can also use Anypoint
Studio’sStudio Visual Debugger to debug
your MUnit tests.

29. MUnit is fully integrated with Anypoint
Studio. You can use Studio’s graphical
interface to:
Create and design MUnit tests
Run your tests
View test results and coverage
Debug your tests

30. The base of the MUnit Framework consists
of MUnit Test Suite files. These files are
the.xml files located under
the src/test/munit folder in your Mule
application’s folder structure. Each MUnit
Test Suite file is a collection of MUnit tests.
It is meant to work on its own, and should
be able to run independently from any
other MUnit test suite files.

31. An MUnit test suite file should contain any
combination of the following components:
Imports
Bean Definitions
Before/After Suites
Before/After Tests
MUnit Tests

32. ThankYou!!!!!!!