Author: Pankuri Bansal & Nikhil Kumar
In this blog, we will explore the process of creating MUnit for the Async Block within Mule 4. We’ll cover how to set up and execute these tests, so you have confidence that your applications are running as expected.
Overview of Async Block
- The Async scope is an incredibly useful feature that allows branch processing to occur concurrently with the main flow. This enables faster and more efficient execution, ultimately enhancing productivity in your operations.
- The main flow seamlessly carries on executing while simultaneously initiating and efficiently processing the asynchronous tasks. This allows for a smooth and uninterrupted workflow, maximizing productivity and efficiency.
- You can enjoy an uninterrupted flow in your processes, even if you have multiple message processors working asynchronously. There is no need to wait for the last processor to finish its task before moving forward. Keep the momentum going and maximize efficiency in your workflows.
Why do we need Munits?
- MUnit is the perfect tool for testing Mule Applications effectively and quickly. It’s a reliable framework that ensures accuracy when testing your applications.
- With its integration and unit test capabilities, this tool can help you boost the quality of your Mule code. This ensures that you get the most out of your applications.
- AI writing assistants provide an easy way to mimic the actions and responses of external systems. This makes it easy for developers to quickly create realistic simulations and tests.
- Generally speaking, developers employ unit testing and validation on their code to confirm its stability. This process allows them to identify any success or failure scenarios that may arise.
Why we use a separate method for MUnit in the Async Block Module?
As previously mentioned, Async block processing is an asynchronous process in which threads execute simultaneously and independently of each other. This makes it a great choice for larger tasks that need to be completed quickly and efficiently. However, the MUnit process is synchronous, which makes it a bit of a challenge.
Solution
- MUnit’s sleep component can be used to provide the main thread with a break for a specific period, based on the number of records. This can help improve the efficiency of the process.
- While the main thread is asleep, other threads in the Batch can execute their tasks independently and will be finished by the time it wakes again. This allows for a seamless transition and execution of subsequent commands without any delay.
- In the MUnit flow, we can validate the outcome of the sync block through assertion.
Implementation of the solution discussed above
- This is the demo application created for the Async block.
- To get started with MUnit, simply right-click on the flow and select “Create New MUnit Test Suite”. This will allow you to easily set up a test suite for your project.
- To ensure success in your test scenarios, it is essential to include all the necessary Mule components in your test suite. By including these components, you can thoroughly assess and validate the functionality of your system, guaranteeing a successful outcome.
- This is the standard approach we commonly follow, but it doesn’t cover all the aspects we discussed earlier.
- As mentioned before, synchronous communication in MUnits and asynchronous communication in the Async block are two different components.
Note:
- It will not cover all the flow components.
- When running the application with a scheduler, there may be instances where you encounter a “scheduler unavailable” message. Rest assured, this is simply an indication that the scheduler feature is temporarily not accessible.
- To effectively implement the solution, it is recommended to incorporate the sleep component into the suite, following the flow reference during flow execution. This adjustment will enhance the overall performance and execution of your workflow.
- Customize the waiting time in the component according to your developers’ preferences. For instance, in the attached screenshot, a delay of 5 seconds has been set.
Let’s run the MUnit suite now.
The execution of all the components necessary for success has been flawlessly achieved.
Sample flow xml:
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core" xmlns:http="http://www.mulesoft.org/schema/mule/http"
xmlns="http://www.mulesoft.org/schema/mule/core"
xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd">
<http:listener-config name="HTTP_Listener_config" doc:name="HTTP Listener
config" doc:id="e435bfb1-da5b-4527-bdfd-a994e26645da" >
<http:listener-connection host="0.0.0.0" port="8081" />
</http:listener-config>
<flow name="poc-async-munitFlow" doc:id="66cbb72c-bbf3-4185-9e65-c5ec3af72e42" >
<scheduler doc:name="Scheduler" doc:id="5c6ba120-9acf-4c44-9355-78f077c576b1" >
<scheduling-strategy >
<fixed-frequency frequency="1"/>
</scheduling-strategy>
</scheduler>
<logger level="INFO" doc:name="Flow Started" doc:id="ae41f6ed-f8fb-49b3-8448-3e1dbccdd559" message="Flow Started"/>
<async doc:name="Async" doc:id="3e5ef42a-7f9c-4f91-9ad7-99312039d977" >
<flow-ref doc:name="Flow Reference" doc:id="15b7278b-ce98-4248-8192-e36c668189b2" name="sf-poc-async-munit"/>
</async>
<logger level="INFO" doc:name="Flow Ended" doc:id="5cea7ced-2420-4307-a5ce-67e6c3374d09" message="Flow Ended"/>
</flow>
<sub-flow name="sf-poc-async-munit" doc:id="ce92aef0-9dda-4a50-b85b-31fd7d46cc6e" >
<ee:transform doc:name="Transform Message" doc:id="f696d5af-3ac0-47da-9ccb-26229d67ce0e">
<ee:message>
<ee:set-payload><![CDATA[[
{
"id": "0"
},
{
"id": "1"
},
{
"id": "2"
},
{
"id": "3"
},
{
"id": "4"
},
{
"id": "5"
}
]]]></ee:set-payload>
</ee:message>
</ee:transform>
<logger level="INFO" doc:name="Log Payload" doc:id="d76e87cc-6e41-4c0a-aca3-58e9f7d28c6a" message="#[payload]" />
</sub-flow>
</mule>
Sample MUnit xml:
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:munit="http://www.mulesoft.org/schema/mule/munit" xmlns:munit-tools="http://www.mulesoft.org/schema/mule/munit-tools"
xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/munit http://www.mulesoft.org/schema/mule/munit/current/mule-munit.xsd
http://www.mulesoft.org/schema/mule/munit-tools http://www.mulesoft.org/schema/mule/munit-tools/current/mule-munit-tools.xsd">
<munit:config name="poc-async-munit-test-suite.xml" />
<munit:test name="poc-async-munit-test-suite-poc-async-munitFlowTest" doc:id="b0d7e3ce-3082-45cb-8e91-bc5e28ffe316" description="Test">
<munit:behavior >
<munit-tools:mock-when doc:name="Mock when" doc:id="5dbed1ad-341b-4ab1-96d4-836588bb9ead" processor="logger">
<munit-tools:with-attributes >
<munit-tools:with-attribute whereValue="Log Payload" attributeName="doc:name" />
<munit-tools:with-attribute whereValue="d76e87cc-6e41-4c0a-aca3-58e9f7d28c6a" attributeName="doc:id" />
</munit-tools:with-attributes>
</munit-tools:mock-when>
</munit:behavior>
<munit:execution >
<flow-ref doc:name="Flow-ref to poc-async-munitFlow" doc:id="c8985e08-3091-4a51-b568-2c9a8437239f" name="poc-async-munitFlow"/>
<munit-tools:sleep time="5" doc:name="Sleep 5 sec" doc:id="78b63af2-04f9-4527-84f2-e7c42e5251ba" timeUnit="SECONDS" />
</munit:execution>
<munit:validation >
<munit-tools:assert-that doc:name="Assert Payload" doc:id="db30102f-6174-4e1c-a6e1-398f926aab16" expression="#[payload]" is="#[MunitTools::notNullValue()]"/>
</munit:validation>
</munit:test>
</mule>