Testing-mule

Transcript

1. TESTING - MULE Presented By Siva K Certified mulesoft Developer
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. The src /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. Run Japex benchmark tests to test individual packages. Additionally, the Mule Profiler Pack can 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 Test Case, so they are compatible with other test cases.
9. unit tests in the Mule TCK: Testing Component : ▪ Abstract Mule Test Case Description : ▪ 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 : ▪ Abstract Connector Test Case Description : ▪ 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 : ▪ Abstract Mule Message Factory Test Case Description : ▪ Provides tests for all the standard methods defined in the Mule Message Factory interface. Add specific tests for converting your transport message to a Mule Message in your subclass.
12. unit tests in the Mule TCK: Testing Component : ▪ Abstract Message Receiver Test Case Description : ▪ Used to test the common behavior of a Message Receiver. This tests receiving messages using mock objects.
13. unit tests in the Mule TCK: Testing Component : ▪ Abstract Component Test Case Description : ▪ This is the base class for unit tests that test custom component implementations. Concrete subclasses of this base class include Default Java Component Test Case, Pooled Java Component Test Case, and Simple Callable Java Component Test Case, each of which contains methods for testing that component type. For example, the Default Java Component Test Case includes methods for testing the creation, lifecycle, and disposal of a basic Java component.
14. unit tests in the Mule TCK: Testing Component : ▪ Abstract Transformer Test Case Description : ▪ 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 as String Byte Array Transformers Test Case.
15. unit tests in the Mule TCK: Testing Component : ▪ Default Mule Context Test Case Description : ▪ 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 called org. mule. tck. junit4. Functional Test Case 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, including Functional Test Component. These classes are described in more detail in the following sections.
17. FunctionalTestComponent : ▪ The previous example of Functional Test Case covers many common (synchronous) test scenarios, where the flow responds directly to the caller. Functional Test Component 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 : ▪ M Unit 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 stack traces that pinpoint message processor failures ▪ integrate with Maven and Surefire for continuous integration support
22. Thank You!!!!!!!