MUnit Towards Automated Unit Test Cases
MUnit Towards Automated Unit Test Cases
Take a look at how you can use MUnit for automated unit testing and learn more about Mule flows and MUnit architecture.
Join the DZone community and get the full member experience.Join For Free
Why Unit Testing?
This is the first question most beginners ask when they struggle to relate unit test cases with real scenarios, like what value-added unit testing is doing. This was my first thought after reading JUnit documents fifteen years back. I am sure most new developers would have similar feelings after reading unit test documents alone, but I realized that unit testing is a powerful tool to release defect-free code to production. The unit testing helps to do regression testing and gives confidence for new developers to make changes to the old codebase.
MUnit For Mule Flows
MUnit is an extension of JUnit. Developers are allowed to write XML-based test cases or Java code-based test cases for Mule flows. This document covers MUnit basics, practical options for different scenarios, and automating the business validations.
How Does the Mule Flow Work?
Mule 4 follows a reactive programming model. The input listeners are event publishers and the flows are subscribers. Every single event message has payload, attributes, variables and exception message. The event message flows from the input source (publisher) to the event subscriber for the incoming requests. The incoming request comes from HTTP Listener/Read file/JMS Queue, etc. While writing unit test cases, developers need to construct the event message, then pass to actual flow. The diagram below illustrates Mule flow architecture.
You may also enjoy: MUnit Testing With Mule 4
Each MUnit test has four sections:
- Execution — The actual testing flows needs to be called. Developers are allowed to set an event payload before calling actual flows.
- Behavior — Any component of the flow the gets mocked (or) introduce any spy component before or after a certain event processor calls.
- Validation — The test conditions (assertions) get executed here. MUnit tools support different types of assertions.
- Before/After the scope — It executes one time before the test begins or after the test case gets completed. These components are applicable to test suites as well.
The diagram below illustrates how the unit test calls the actual flow and gets back the result.
Assert Event ProcessorAssert event processor helps to validate the event processor contents. MUnitTools supports various types of assertions.
MUnitTools:equals() — Compare string values with payload, variables of the output event.
MUnitTool:notNullValue() — Check the event payload is not null value. Refer the link for all the matches: https://docs.mulesoft.com/munit/2.2/munit-matchers.
Refer to the codebase (mocking-event-processor-test-suite.xml) on mule-munit-samples for how to use the assertions.
Mocking Event processor — Any component could be mocked in the flow wherever it required. Suppose, calls going out of the flow (or) external system, mocking helps to generate custom output and also get details from previous event processors. Developers allowed to set variables, payload, and attributes on the mocking component.Refer the codebase(mocking-connector-test-suite.xml) on mule-munit-samples.
- Set Event message — It generates a Mule event message before calling the actual flow for testing. Let us assume the HTTP listener is getting request from outside. Set the event processor allowed to simulate the HTTP request. Refer to the he codebase (mocking-event-processor-test-suite.xml) on mule-munit-samples.
- Spy Event processor — This is a very important component for validating the transformation component(dataweave). Let us assume multiple business scenarios on the transformation component. Developers are allowed to set the input for each scenario then validate after the transformation gets executed for each scenario. Refer the codebase (testseteventservice-test-suite.xml) on mule-munit-samples.
- Verify the Event processor — It helps to verify whether a particular event processor gets called or not, and also how many times the event processor gets called. Refer to the codebase (mocking-connector-test-suite.xml) on mule-munit-samples.
- Custom Assertion — Developers want to test special functionality which is common across the project. Custom assertion allows writing Java code as a custom assertion. Refer to the codebase (testcustomassertion-test-suite.xml) on mule-munit-samples.
- XML/JSON payload test — In the real projects, XMLs/JSON messages could be validated for unit testing. Custom connectors help to validate the XML/JSON payloads. Refer to the codebase (testxml-test-suite.xml, testxml-test-suite.xml) on mule-munit-samples.
- Mocking Database — MUnit supports mocking well-known database such as DB2,Oracle, SQLServer, MySQL, PostgreSQL. Please refer the link for more details.
The framework code helps unit testing automation. The flow has n number of business scenarios that could be easily simulated with just input/out file with no need to write the test case for every scenario. it validates all the business scenarios based on the input and output files which include positive scenarios and error scenarios.
It takes the input payload via flat-file and validates the output file, which was placed with the same input filename.
The above diagram illustrates how the automation works by taking input payload from the input folder and checking out the output folder with the same file name for verifying the result. Please refer to the code base (mule-munit-automation-framework).
The article explains where to start and the expected nd state of your unit testing roadmap. Unit testing is strongly recommended for all Mule flows and ensures that covers it all the business scenarios of DataWeave code. The coverage report does not cover DataWeave code and only shows code coverage for the flow path. Developers have to manually review the business logic code and make sure that unit testing gets covered.
Opinions expressed by DZone contributors are their own.