Exploring Unit & Integration Testing — MUnit
In the last two stories, we created 1. a simple Mule application and 2. discussed API contracts and API design. Today I will be creating unit test cases and exploring MUnit in Mulesoft.
I will take a quick minute to discuss Test-Driven Development(TDD). Some of the projects I worked on required TDD and that's how I became aware of this agile methodology.
I would recommend reading this bliki by Martin Fowler. TDD started as part of extreme programming. The idea was to provide guidance to the developers for creating code that fulfills all the requirements. I feel the benefits are many but to note some :
- TDD allows to capture the requirements first and then the developer goes into coding.
- The developer has a fairly good idea of what the code needs to look like as he just created a unit test case.
- This creates a constant feedback loop and allows the developer to fix any and all code issues immediately and on the spot.
Think of it as a shopping list that lists down all items required to be purchased. The list creates an inventory which is an easy way to not miss anything. Also thinking ahead allows us to not miss anything. We have discussed the basics and let's deep dive now.
What are we doing today?
For this demo, I will be setting up below.
- Mule application
- MUnit
I have linked the mule application, I am using. The idea is to create both positive and negative test scenarios. This ensures the application operates as expected. The test can range from matching HTTP return codes to asserting the payload. Let's move on to the next step. Right-click on the flow and navigate to MUnit — Create blank test for this flow.
Next use Set Event to inject the payload to the POST API.
Payload value : {"ACCOUNT_TYPE": "Business","ACCOUNT_ID": 999999,"STATUS_UPDATE_DATETIME": "2021-10-21","CURRENCY": "USD","OPENING_DATE": "2018-08-19","STATUS": "Disabled"}
Finally, use Assert equals to check if the payload is returning code: “201”.
We are using a logger before assertion to log the response payload. Below is the INFO log. The assertion matches with the expectation of “201” and the test passes.
INFO 2022-07-15 19:58:48,648 [[MuleRuntime].uber.01: [wholesale-banking-api].validation.CPU_LITE @68fd67f0] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: Logging the payload : {"code": "201","message": "Account created","dateTime": "2022-07-15T19:58:48Z","transactionId": "0001234"}
MUnit window on the left panel will show a green bar as the test passed.
We covered the positive scenario. Let’s move on to the negative scenario. What if the account creation failed, the message returned — “Account already exists” and status code- 409.
As the returned status code is not set, the test fails.
Once we setup the status code correctly, the test will pass.
Congratulations gang, we just set up two of the most common scenarios of success and failure. If you have been with me this far, hang on and we will explore some more useful MUnit components soon.
