MUnit – Test your mule flow – Part 2

This blog is the continuation of my previous blog about MUnit, so if you have not read it yet I will highly recommend you to go thorough it before continuing MUnit – Test your mule flow – Part 1 or you can watch the video tutorial at youtube https://www.youtube.com/watch?v=on7uQpWXV1E&feature=youtu.be

Let’s get going, If you remember last time we created a mule project with four flows

• Main Flow
• Decision Flow
• Two sub-flows

So what we are going to do is that we will be writing Unit test case for decision flow and Functional test case for Decision flow and sub-flows, with this we will be able to cover both Unit test and Function test case.

Unit Test Case

As I explained in the last blog while doing unit testing we try to isolate the part of code that is under test as much as possible and if it depends on some other part of code we try to mock it with replacement dummy functions. Same is the case with Mule flows when we write unit test case for a flow and if the flow under test is calling other flows we try to mock those called flows and test the single flow in its entirety.

When doing unit tests, you isolate your flow from third-party systems and other flows and trust they work as expected. In turn, you must test each third-party system or flow with its own, specific test.

If the flow takes different actions based on different values of the payload or on the contents of a variable, we should design more that one test for that flow.

One important point to remember is in MUnit you don’t mock or verify flow-ref, we mock or verify the flow andsub-flow.

MUnit Initialization

Any MUnit test case starts with the initialization of MUnit and importing the xml config file where you have written your flows that you want to test.

<munit:config name="munit" doc:name="MUnit configuration" />
<spring:beans>
	<spring:import resource="classpath:munit-demo.xml" />
</spring:beans>

Unit Test Case 1 -> sub-flow-test-suite.xml

Since our smallest part of code are the sub-flows, we will write the unit tests for them first.

<munit:test name="sub-flow-test-suite-decision1SubFlowTest" 		description="Test">
		<flow-ref name="decision1SubFlow" doc:name="Flow-ref to decision1SubFlow" />
		<munit:assert-on-equals 			message="Sorry did not got expected Value i.e. decision1 insted go #[payload]" 			expectedValue="#['decision1']" actualValue="#[flowVars.decisionVariable]" doc:name="Assert Equals" />
	</munit:test>
	<munit:test name="sub-flow-test-suite-decision2SubFlowTest" 		description="Test">
		<flow-ref name="decision2SubFlow" doc:name="Flow-ref to decision2SubFlow" />
		<munit:assert-on-equals 			message="Sorry did not got expected Value i.e. decision2 insted go #[payload]" 			expectedValue="#['decision2']" actualValue="#[flowVars.decisionVariable]" doc:name="Assert Equals" />
	</munit:test>

Let’s understand what’s going on here. Since the task of these sub-flows are just to set the flow variable named decisionVariable we are going to simple make a flow reference to these two flows and use munit:assert-on-equals function to check the value of flow variable to be equal to the expected value.

Unit Test Case 2 -> decision-flow-test-suite.xml

In our flows decision flow is the place where we decide based on the payload sent by main flow which sub-flow to go using the choice router of mule and then those sub-flows set the decision variable into flow vars. So we will be writing two test cases for decision flow (actually four) where first we will test that the correct sub-flow is being invoked if we send the proper payload and then in a separate test case we will test if the correct flow variable is being set by sub-flows. Since there are four possibilities i.e. invocation of two sub-flows and return of two different values of flow variable that is the reason I said four test cases.

Testing Invocation of sub-flows

<munit:test name="decision-flow-mock-test1-suiteTest" 		description="MUnit Test">
		<munit:set payload="#['value1']" doc:name="Set Payload as Value1" />
		<flow-ref name="decisionFlow" doc:name="decisionFlow" />
		<munit:assert-on-equals 			message="Did not get decison1 for value 1 insted got #[flowVars.decisionVariable]" 			expectedValue="#['decision1']" actualValue="#[flowVars.decisionVariable]" 			doc:name="Assert Equals" />
	</munit:test>

In this test case, we are setting the payload value before calling the decisionFlow using the flow-ref and then by using the mock:verify-call, we verify that the correct sub-flow is being invoked.

In verify-call important thing to notice is that I have used matchContains matcher of munit.

When mocking or verifying a sub-flow and using the name attribute, always use the MUnit matcher matchContains

This is not needed when verifying or mocking flows, only for sub-flows. I have not given the xml part of send test I leave it up-to you to try and implement it.

Testing flow variable value

<munit:test name="decision-flow-mock-call-1-test1-suiteTest" 		description="MUnit Test">
		<munit:set payload="#['value1']" doc:name="Set Payload as Value1" />
		<flow-ref name="decisionFlow" doc:name="decisionFlow" />
		<mock:verify-call messageProcessor="mule:sub-flow" 			doc:name="Verify Call" times="1">
			<mock:with-attributes>
				<mock:with-attribute name="name" 					whereValue="#[matchContains('decision1SubFlow')]" />
			</mock:with-attributes>
		</mock:veri

This test case is vary similar to the test case for sub-flows only difference is that we are setting the payload value and instead of calling sub-flow we make a call to decision flow.

The Assert part of decision variable is completely same. We could have easily merged this test case with the invocation test case but it’s always a good idea to separate your test case so that they have only one responsibility of testing only one function

Again I left the second test case implementation for you to try.

I will keep this blog till this point in the next and last part of this blog series we will see how to unit test our main flow, testing main flow is going to be tricky because we will require to mock the flow reference calls, I will be showing how to do that and we will also see how to write Functional test i.e. end to end test of our flow.

Video Tutorial

I hope you liked the blog, please like and share and subscribe my youtube channel for latest technical blogs.