MuleSoft — MUnit Reusable Test Suites

Reading Time: 6 minutes

I will create a generic test suite using parameterisation in MuleSoft MUnits to test different test scenarios (e.g.: Positive Test, Negative Test/Specific Error scenarios).

Test cases will be reusable using parameterised test suites, which run the same test cases across APIs (across different resources/endpoints) with different inputs.

The below steps will help generate these reusable test cases.

Once API development is completed, start by creating a blank MUnit test. Add MUnit Config to include the parameterised file. For example, the system API name (sfdc-sapi). All these test cases are related to happy/positive test suites.

Test Suite: sfdc-sapi-test-suite-positive.xml

File Name: common/parameterizations-positive.yaml

You can define all parameters which are required for the test case. For example, Flow Name, Input Payload, Input Attributes and Process name need to be Mocked, Mock Attribute Name, Mock Processor Name, Output from Mock Processor, Out Payload from Calling Flow, Error Type and HTTP Status. You can add/delete as per your requirements.

Positive Test Case: postOrders
Test: salesforce-system-api-positive-test
Global Configuration: MUnit

Test Suite: salesforce-system-api-positive-test

salesforce-system-api-positive-test

Details about each component:

Add the Munit tools as required by your test flows and externalise each value with a dollar sign and curly brackets ${mockParam}.

Mock Processor with Attribute name and value:

  • Provide Payload
  • Provide Attribute (if needed)
Behaviour: Mock When

Set Event

  • Set Input Payload
  • Set Input Params (Query Params and Header Params)
Execution: Set Event (1. Payload)

Execution: Set Event (2. Attributes)

Name of the Flow which needs to be tested.

Behaviour: Call flow-ref

Set Output Payload Variable (Out Payload/Response Payload value from current flow). This is an optional step. You can directly Assert Equals as mentioned in the below step.

Validation: Create OutPut Payload

Assert Equals to Validate Out Response

Validation: Assert That (Payload Validation/Matching)

Similarly, you can add test suites for implementation as well.

Positive Test case: POST /orders — Implementation

All these test cases are related to unhappy/negative test suites.

Test Suite: sfdc-sapi-test-suite-negative.xml

File Name: common/parameterizations-negative.yaml

You can define all parameters which are required for the test case. For example, Flow Name, Input Payload, Input Attributes and Process name need to be Mocked, Mock Attribute Name, Mock Processor Name, Output from Mock Processor, Out Payload from Calling Flow, Error Type and HTTP Status. You can add/delete as per your requirements. Here, we are going to test HTTP:BAD_REQUEST scenario.

Negative Test Case: postOrders (BAD REQUEST)
Test: salesforce-system-api-negative-test
Global Configuration: MUnit

Test Suite: salesforce-system-api-negative-test

salesforce-system-api-negative-test

Details about each component:

Add the MUnit tools as required by your test flows and externalise each value with a dollar and curly brackets ${mockParam}

Mock Processor with Attribute name and value

  • Provide Payload
  • Provide Attribute (if needed)
Behaviour: Mock When

Set Event

  • Set Input Payload
  • Set Input Params (Query Params and Header Params)
Execution: Set Event (1. Payload)
Execution: Set Event (2. Attributes)

Name of Flow which needs to be tested

Behaviour: Call flow-ref

Assert Equals to Validate HTTP Status Code (user can also validate out payload as well if needed and/or required).

Validation: Assert Equals (HTTP Status Code)

Similarly, you can add test suites for implementation as well.

Negative Test case: POST/orders — Implementation

Benefits of implementing these MUnit Test suites:

  • Limited knowledge will be required to write MUnits.
  • New Scenarios/Test Cases can be easily added by just creating in/out Payload and in/out Attributes without modification of existing test suites.
  • Easily incorporate multiple test cases for Positive/Negative Test cases (for example, Experience API, System API), EAPI/SAPI will have direct 1-on-1 calls, whereas Process API (PAPI) will have multiple System API calls which require multiple mock-when processors (Note: Refer to the Multiple Mock Scenarios section.)
  • MUnit Coverage can be easily increased or achieved ~100%.

Limitation:

The above test cases can handle only 1 mock-when (but you can add For-Each and customised mock-when as per your use case).

Test Results: (postOrders)

Positive Test Suites

Test Result for Positive Test Case
Test Coverage Report for Positive Test Case

Negative Test Suites

Test Result for Negative Test Case
Test Coverage Report for Negative Test Case

Note: Here, you see the test result as 75% (in the negative test case) because post processors after HTTP Request were not executed, and it is the natural behaviour of the test case.

Run both Test Suites (Positive and Negative) at the same time.

Test Results for Positive and Negative Test Cases
Test Coverage Report for Positive and Negative Test Cases

Note: Here, you see the test result as 100% because both test cases were executed successfully.

Multiple Mock Scenarios

  • YAML File for all Test Suites
  • Sample Test Suite scenario
  • Use can set error scenarios as I did for Variables and Payload.
YAML File contains Count for Variables and Payloads For Mock-When Operation
Test Suite with Multiple Mock-When cases (1st For-Each to iterate Variables and 2nd For-Each to iterate Payload)
1st For-Each (Variable Iterates) — Create Variables
Mock-When: Set Variables (Not Payload)
2nd For-Each (Payload Iterates) — Create Variables
Mock-When: Set Payload (Not Variables)

Let’s get started.
Reach out to us
for a conversation!

Fill in the form below and we will get back to you