MUnit: Mule application unit testing best practices

MUnit Application Testing

Mule Integration Framework facilitates unit testing of mule applications through writing test cases leveraging the power of its native testing framework: MUnit. In the world of software development, unit testing plays a vital role on validating the correctness of a piece of code so that the potential problems and root causes can be isolated at an early phase and can be fixed before the code breaks any dependent code in release or in production environment.

This article encompasses the idea of writing MUnit test case in the test-driven development environment of Mule along with recommendations on what we should consider while writing a good test case.

Scenario: The underlying concept here is to capture a change requirement scenario. Following is the target flow – as part of some change requirement the dataweave transformation of the very first transform message component has been changed. In the existing project, there is a MUnit test case to test the main flow. Hence, to validate the outcome of modified transformation, it is wise to create a separate unit test case only for the transformed component with positive/negative cases.

MUnit test flow

Brief description of the test suit to validate Transformation output:

Here no flow-ref has been used to invoke the sub-flow since our scope is only to verify the transformation output.

Pre-requisites:

To initialize the test suit each MUnit test file must contain the following:

  • munit:config
  • An import section (defines the files needed to run the test suit)
MUnit config
MUnit test suit

Here is how it works:

  1. At the beginning of the test case, the Set Message processor is used to locate the payload that has to be passed through the transformation. The location of the file is /example folder under src/test/resources and The MIME type is mentioned as text/json to reflect the original payload type.
MUnit - Set Message Processor
  1. The next two message processors are used to convert the original payload to the form as it is received by the target transform message component in the original sub flow. The set variables transformer is used to pre-set some dependent variable values that have been used in the transformation of payload.
  2. Payload Transform is the transform message component in this case which refers to the original dw file containing the transformation of the payload. Here, it is important to refer to the original dw file rather than copying the transformation body so that the test case will ensure the validation of further changes in the same transformation in future. Build Actual and Expected Values: this has been used to create two variables to contain the expected response and actual response from the transformation that occured immediately before this. Here again, the expected response is kept in a xml file under the location: src/test/resources.
  3. Finally, Assert component is used to check whether the actual output matched with the expected output.
MUnit Payload transform message
MUnit payload
MUNit output application json

Considerations for simple and efficient MUnit test case:

  • A good MUnit test case must be simple and target oriented ie. it should only focus to validate a specific function or processor of a flow. If there are multiple optional paths present in a flow, separate test cases should be created to validate each of them.
  • While writing a test case, we should isolate our code block. The code should be independent of any external systems or applications. If the code is dependent on some other part of the code it is suggested to mock that part.
  • Maintaining meaningful naming convention aligned with the target flow and functionality is another important aspect. If request/response example files are used, the location and name should be purposeful as well; this will lend to its readability
  • Writing MUnit test cases becomes easier when the target codes are properly modularized and structured. Hence, it is of important to take into consideration the test cases while writing the code which will eventually bring simplicity and more manageability in generating test cases.

Incepta is a certified MuleSoft partner with an experienced team of experts in MuleSoft development and consulting. Visit our website: www.inceptasolutions.com or email us at hello@inceptasolutions.com   

Written by Jakia

April 28, 2020

You May Also Like…

We're Here To Help!

Office

CANADA:
Suite 303, 2585 Skymark Avenue,

Mississauga, ON, L4W 4L5

USA:
1177 High Ridge Road
Stamford, CT

Email Us

hello@inceptasolutions.com

Pin It on Pinterest