V-Soft's Corporate Headquarters

101 Bullitt Lane, Suite #205
Louisville, KY 40222

TOLL FREE: 844.425.8425
FAX: 502.412.5869

Denver, Colorado

6400 South Fiddlers Green Circle Suite #1150
Greenwood Village, CO 80111

TOLL FREE: 844.425.8425

Chicago, Illinois

311 South Wacker Dr. Suite #1710, Chicago, IL 60606

TOLL FREE: 844.425.8425

Madison, Wisconsin

8401 Greenway Boulevard Suite #100
Middleton, WI 53562

TOLL FREE: 844.425.8425

Atlanta, Georgia

1255 Peachtree Parkway Suite #4201
Cumming, GA 30041

TOLL FREE: 844.425.8425

Cincinnati, Ohio

Spectrum Office Tower 11260
Chester Road Suite 350
Cincinnati, OH 45246

Phone: 513.771.0050

Raritan, New Jersey

216 Route 206 Suite 22 Hillsborough Raritan, NJ 08844

Phone: 513.771.0050

Toronto, Canada

1 St. Clair Ave W Suite #902, Toronto, Ontario, M4V 1K6

Phone: 416.663.0900

Hyderabad, India

Incor 9, 3rd Floor, Kavuri Hills
Madhapur, Hyderabad – 500033 India

PHONE: 040-48482789

Bangalore, India

3rd Stage Behind Hotel Leela Palace
Kodihalli, Bangalore - 560008 India

Understanding MUnit Test In MuleSoft Mule 4

MuleSoft Mule 4 MUnit

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.

Comparing Mule 3.8 and Mule 4 MUnit

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

How to create Munit Test in a flow

Then it will automatically generate a MUnit configuration file with the MUnit Scalitone.

MUnit configuration file

Figure 3: Applying MUnit test on a flow

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.

Set Event Structure in MUnit and its use

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.

Mock When in Mule 4 MUnit

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>


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.

Assert That structure in Munit and its use

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.

Verify Call structure and its use

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:

How to run Munit Test using Mule 4

Figure 8: Run the MUnit test cases

Successful Munit Test using Mule 4

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:

If any error occurs after run the Munit test cases

Figure: MUnit displaying error message


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.

API-led Connectivity Whitepaper


Topics: MuleSoft, Mule 3, Mule 4, MUnit

Get Weekly Updates

A Comprehensive Guide to MuleSoft Mule 4