In unit testing, individual units of source code are tested to check whether they are fit for use or not. In the case of writing test cases in Java, Java programmers use Junit framework to write test cases. Similarly, MuleSoft provides a framework called MUnit. This enables programmers to write automated test cases for APIs and integrations. The Mule 4 MUnit has been updated to rectify expression language and simplify management. This speeds up the development process for applications, compared to Mule 3.
How to Create Munit Test In a Flow
In Mule 3.8, all Mule functions were in a single category. But, Mule 4 has two categories: Munit and Munit tools.
This is the main flow where Munit is created for testing the application and this flow contains Http listener, MySQL database, Transform Message, logger and Set Payload. For creating Munit tests for applications: Right-click on the flow> Munit>Create new Munit
Then it will automatically generate a MUnit configuration file with the MUnit Scalitone.
Figure 3: Applying MUnit Test Flow
Here different event processors for testing the application are used like Set Event, Mock When, Assert That and Verify Call. Let’s discuss, how all these processors are working.
Set Event
At the beginning of a Munit test, this processor can be used to indicate that the first message is sent to the flow for the purpose of testing. The set-event has the cloneOriginalEvent property. If set true, then it clones the event produced by the code and by default this property is false.
Here a value is passed as “'requestPath':'/listener'” which will point to the main flow. We can pass a value as queryParams also.
Figure 4: Set Event Structure in MUnit and its use
- Value: The content of the property
- Encoding: Defines the encoding of the message. This attribute is optional.
- Media Type: Defines the mime type of the message. This attribute is optional
Mock When
The ‘Mock When’ processor allows you to mock an Event Processor when it matches the defined name and attributes. We can use Mock when the message processor is having different scenarios. For example, let us assume we developed a Mule application and required to be tested. If the database in this application and the connector used in the message processor are not ready to accept any request, we still we want to test it. In some cases, Mock When is required for a database connector.
Figure: 'Mock When' on Database
The image above provides the processor as “db:select” and attribute as “config-ref” by looking into database configuration. For mocking of the database we passed one dummy database payload in value as “MunitTools::getResourceAsString('sample_payloads/database_payload.json'\)”, inside the folder location where it will compare with the actual database payload. If dummy payload is equal with the actual one then only Mock will work properly.
<db:select doc:name="DB" doc:id="9b207dbe-26f7-4d18-920f-b34d916fd475" config-ref="Database_Config">
<db:sql >select * from employee;</db:sql>
</db:select>
Assert That
The ‘Assert That’ event processor allows you to run assertions in order to validate the state of a Mule event’s content. This is an event processor that is used to validate the Mule event after the production code runs.
For example, to assert that a payload is equal to a certain value, you can configure the Assert-That processor using the equalTo() matcher.
Here “Expression” works as an actual payload and “Is” works as an expected payload. So, the actual payload will compare with an expected payload.
For expected payload we have passed dummy response as: “MunitTools::equalTo(MunitTools::getResourceAsStream('scaffolder/response/responsepayload.json') replace '\r' with '')” which is located inside the folder.
Figure: Assert That structure in MUnit and its use
Verify Call
This processor is defined to verify if any processor was called. Here we can validate if a specific message processor has been called by using a set of attributes with a specific number of times.
- Processor: Describes which event processor you want to mock. The description takes the form {name-space}:{event-processor-name}. It supports regular expressions.
- Times: It defines the verification as successful if the event processor was called N number of times.
- At least: Defines the verification as successful if the event processor was called a minimum of Nnumber of times.
- At most: Defines the verification as successful if the event processor was called a maximum of Nnumber of times.
Figure 7: Verify Call structure and its use
How to Run a Munit Test
Just right click on the Munit test and Run Munit test, as demonstrated below:
Figure 8: Run the MUnit test cases
Figure: Successfully executed after running the MUnit test cases
Once the MUnit suite is triggered, then it will provide details such as errors, failures (if any), coverage report, and test status. In the above image, the green color indicates the successfully executed and passed test case. It also generates a report with overall coverage.
View the coverage report to find out the test result report. The coverage report provides metrics on how successfully the Mule application has been executed by a set of MUnit tests. MUnit coverage is based on the volume of MUnit message processors executed. MUnit coverage report provides the following result:
- Application overall coverage
- Resource coverage
- Flow coverage
Generated error result would displayed as:
Figure: MUnit displaying error message
Conclusion
Compared to MUnit in Mule 3, in Mule 4, Munit has many naming conventions changed. The improvements made in Mule 4 make it easier to understand and improves performance scope of MuleSoft applications to perform at a higher operational scale with improved API connectivity.
