Testing - Mule

Presented BySindhu VL

Testing :•This section describes how to test your

Mule application.•Introduction to Testing Mule•Unit Testing•Functional Testing•Testing Strategies•MUnit

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.

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

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.

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.

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:

• 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.

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.

unit tests in the Mule TCK:Testing Component : Description :• AbstractConnectorTestCas

e• Used to test the common

behavior of a connector. This tests dispatching and sending events using mock objects.

unit tests in the Mule TCK:Testing Component : Description :• AbstractMuleMessageFact

oryTestCase• Provides tests for all the

standard methods defined in theMuleMessageFactory interface. Add specific tests for converting your transport message to a MuleMessage in your subclass.

unit tests in the Mule TCK:Testing Component : Description :• AbstractMessageReceiver

TestCase• Used to test the common

behavior of aMessageReceiver. This tests receiving messages using mock objects.

unit tests in the Mule TCK:Testing Component : Description :• AbstractComponentTestCa

se• This is the base class for unit

tests that test custom component implementations. Concrete subclasses of this base class includeDefaultJavaComponentTestCase,PooledJavaComponentTestCase, andSimpleCallableJavaComponentTestCase, each of which contains methods for testing that component type. For example, theDefaultJavaComponentTestCaseincludes methods for testing the creation, lifecycle, and disposal of a basic Java component.

unit tests in the Mule TCK:Testing Component : Description :• AbstractTransformerTestC

ase• 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 asStringByteArrayTransformersTestCase.

unit tests in the Mule TCK:Testing Component : Description :• DefaultMuleContextTestC

ase• Tests the creation and

disposal of the Mule context.

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.

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.

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

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

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

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 

Thank You!!!!!!!