Writing MUnits with Mulesoft
I’ve always procrastinated writing MUnits for my projects. But once I invested time learning about it, I am in love with it and make sure every service I build has MUnits before it gets deployed to Production. Here’s a quick start guide to help you get started with writing MUnits for your projects.
Pre-Requisite
Make sure your environment is setup correctly. You have a Global Property (Configuration) setup with the right env value.
<global-property doc:name="Global Property" doc:id="d9ba1573-7be0-4cb5-a270-047b742a0b2d" name="env" value="test" />And if you are using a masterKey to encrypt secrets within the YAML, you have another Global Property with the masterKey. You wouldn’t typically store your actual masterKey within the config file, unencrypted. But you could keep a placeholder value that you can use for local development, and then store the actual masterKey for other environments (sandbox/beta/prod) into Jenkins and push it out to Runtime as part of your CI/CD process.
<global-property doc:name="Global Property" doc:id="109d5415-f22a-473f-bb4c-d38da283da5b" name="masterKey" value="placeholder" />Create a YAML for your test environment. You should not be putting any credentials into the test YAML file because the goal is to mock external system interaction.
Setting up Test Suites
Navigate to your anytime project in AnypointStudio that should have a /src/test/munit directory. Right click on the directory and select a New > MUnit Test. The resulting file is a Test Suite where you can create multiple test cases that are related.
Within the file, drag on a Sub Flow and and MUnit Test onto the suite. I will be using the Sub Flow to mock any of the external API requests.
The MUnit Test is where I’ll be creating my first unit test that contains a section for Execution, Behavior and Validation.
Setting up Execution
Drag MUnit > Set Event to setup the incoming payload to the endpoint. The payload can be added directly within the Set Event component, or a preferred and better way of organizing your inputs and mocks is to save them in files and load them up from the files.
The getResourceAsString method enables you to read the content from the file as String. Setting the right Media Type and Encoding enables you to parse the content in the desired format.
#[MunitTools::getResourceAsString('request/account-opening-post-flow.json')]If there are any variables that you’re setting from the attributes (headers/uri, etc), make sure to initialize them within your execution flow.
Setting up Behavior / Mocks
Most likely, you might end up or want to execute different input payloads for a given endpoint to test all use cases or to attain a higher coverage. It’s advisable to create a sub-flow within the test suite with all the mocks and reference the sub-flow from each test.
To setup a mock, drag the MUnit Tools > Mock when component onto the sub-flow. Pick the appropriate processor and conditions to identify the mocking criteria use the getResourceAsString() method to get the sample Mock response from a file with the appropriate Media Type and Encoding from the dropdown.
#[MunitTools::getResourceAsString('response/jx-CustSearch-response.xml')]
There are other things that you can mock, e.g. HTTP Status Codes, variable assignment, etc.
Mock a HTTP Status Codes:
#[{'statusCode': 200}]
Mock variable assignments:
#[%dw 2.0 output application/json --- [{"ssn": "100901000", "MemberGroup": "15"},{"ssn":"100901001","MemberGroup":"16"}]]
Setting up Validation
The last piece of creating an MUnit test is to validate that the tests work as expected. You can create assertions at this stage and validate that certain elements in the response as what you expected based on the mocks. Drag the MUnit Tools > Assert equals onto the Validation section and setup assertions that you’d like to validate.
Now, you’re ready to run or debug your test suite. Right click on the test suite file and selection from the options.
