Testing - Mule

Testing in Mule - MunitPresented BySindhu VL

Testing :This section describes how to test your Mule application.Introduction to Testing MuleUnit TestingFunctional TestingTesting StrategiesMUnit

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 Maventestsproject 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 customizationsFunctional testing of your Mule configuration and setupFunctional and unit testing of your custom modules and transportsIntegration testing of multiple modules, transports, and transformers, etc.System testing of transports that connect to embedded or external servicesStress 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 teststo test individual packages. Additionally, theMule 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, visitMuleForge.

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.jarfile, such asmule-core-3.0.0-tests.jarfor Mule version 3.0.0. All unit tests inherit fromorg.mule.tck.AbstractMuleTestCaseThese 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 doesnt need to worry about writing new test classes for their test cases each time.The abstract test cases in the TCK use JUnitsTestCase, so they are compatible with other test cases.

unit tests in the Mule TCK:Testing Component : Description :AbstractMuleTestCaseA 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 :AbstractConnectorTestCaseUsed 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 :AbstractMuleMessageFactoryTestCase

Provides tests for all the standard methods defined in theMuleMessageFactoryinterface. Add specific tests for converting your transport message to a MuleMessage in your subclass.

unit tests in the Mule TCK:Testing Component : Description :AbstractMessageReceiverTestCaseUsed to test the common behavior of aMessageReceiver. This tests receiving messages using mock objects.

unit tests in the Mule TCK:Testing Component : Description :AbstractComponentTestCaseThis 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 :AbstractTransformerTestCaseUsed 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 :DefaultMuleContextTestCaseTests 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 abstractJUnittest case calledorg.mule.tck.junit4.FunctionalTestCasethat runs Mule inside a test case and manages the lifecycle of the server. Theorg.mule.tck.functionalpackage 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.FunctionalTestComponentcan help support richer tests, such as:Simulating asynchronous communicationReturning mock data to the callerCommon 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: youll gain the security of a safety net catching any regression or incompatible change in your applications before they even leave your workstation.Well 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 testWith 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, youll 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 processorswrite tests in XML or Javacreate tests in the Anypoint Studio drag-and-drop interfaceinsert spy functionality to track what happens before and after a message processor is calledview coverage reports in Studiorun tests with your pluginsaccess detailed Mule stacktraces that pinpoint message processor failuresintegrate with Maven and Surefire for continuous integration support

What is Munit ?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.

Purpose of MUnit : Create your Mule test by writing Mule codeCreate your Mule test by writing Java codeDisable flow inbound endpointsDisable endpoint connectorsMock outbound endpointsMock message processors

Create not only unit tests but also integration tests in a local environmentMUnit allows you to start a local FTP/SFTP, DB server or mail serverCall the Mule client from Mule codeAssert flow exceptionsSpy any message processorVerify message processor calls

Enable or disable particular testsSee assertion/error reports with Mule stack traceExtend the MUnit framework with pluginsCheck visual coverage in StudioDebug your tests with Studio

MUnit Compatibility :MUnit is divided among several sub modules. From a users point of view there are only two that are really important. Both modules are compatible amongst themselves.The important sub modules are:

MUnit VersionMule MUnit Support Version1.0.x3.6.x, 3.7.x1.1.x3.6.x, 3.7.x

Mule MUnit Support :The Mule MUnit Support module is meant to follow Mule ESB releases:Mule MUnit Support VersionMule ESB Version3.6.x3.6.0 to 3.6.x3.7.x3.7.0 to 3.7.x

MUnit and Anypoint Studio :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 StudiosStudio Visual Debuggerto debug your MUnit tests.

Using MUnit in Anypoint Studio :MUnit is fully integrated with Anypoint Studio. You can use Studios graphical interface to:Createand design MUnit testsRunyour testsViewtest results and coverageDebugyour tests

MUnit Suite :The base of the MUnit Framework consists ofMUnit Test Suite files. These files are the.xmlfiles located under thesrc/test/munitfolder in your Mule applications 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.

Components of an MUnit Test Suite :An MUnit test suite file should contain any combination of the following components:ImportsBean DefinitionsBefore/After SuitesBefore/After TestsMUnit Tests

ThankYou!!!!!!!