Mule Unit Tests with Inbound Message Properties in Session or Invocation Scope

By | February 28, 2014

My very first blog post described how to unit test Mule transformers that access session and/or invocation scoped message properties. To accomplish that I developed a new, better, Mule message. In this post I will describe how this new Mule message class can be extended to allow for session and/or invocation scoped message properties to be set on the message before it is being sent to a Mule flow.

Test Mule Flow

The unit test that will be implemented later will use an extremely simple Mule flow. Graphically, it looks like this:

As you can see, the flow consist of just a request-response VM endpoint and a component that sets a session-scoped property on the messages passing through it. The flow XML looks like this:

In the flow XML we can see that the session property set is named “outboundSessionProperty” and it is set to the value of a session property named “inboundSessionProperty”. Aha! We will have to set a session property on the message sent to this flow in order for it to produce a result in the “outboundSessionProperty” session property.

Log4J Properties File

In order to see log generated by Mule, a small Log4J properties file is needed. It is to be named “log4j.properties” and placed in “src/test/resources” in the example project.

Unit Test

The unit test simply creates a Mule message with an arbitrary payload, sets a session property on the message and sends it to the VM endpoint in the test flow. When the response is received, the unit-test verifies that the session property “outboundSessionProperty” has the expected value. For our convenience, the response message is also logged to the console so that we can inspect it.

The Old New Message

First we will attempt to use the new, better, message presented in the old blog post. For convenience, I reproduce it here:

Run the Unit Test – First Attempt

If we now run the unit test, we will see the following output on the console:

Obviously something went wrong and, in addition, we can see that the unit test indeed failed.

The New New Message

Lets add a couple of instance variables and two methods to the DefaultTestMuleMessage class. This is the complete, modified, class:

Note that:

  • There are two new instance variables: mSessionPropertiesMap and mInvocationPropertiesMap. These maps are to hold session and invocation scoped message properties. The reason for adding these instance variables and not using the message properties context in the superclass is that the message properties context is private and cannot be accessed from the child class.
  • There are two new methods, setSessionProperties and setInvocationProperties, that both override methods in the superclass.
    Mules default behaviour is to set maps containing session and invocation properties immediately prior to a message entering a flow, thus these scopes will always be empty.
    The added methods ensure that any properties in respective scope are copied to the new map that is being set.

Run the Unit Test – Second Attempt

If we now run the unit test there should be a green bar indicating success.
In the console we can also see the response message received from the test flow:

Note the session scoped properties at the end of the printout.

5 thoughts on “Mule Unit Tests with Inbound Message Properties in Session or Invocation Scope

  1. Vince

    I tried this but I’m getting an exception:

    Caused by: org.mule.api.transport.NoReceiverForEndpointException: There is no receiver registered on connector “connector.VM.mule.default” for endpointUri vm://vmInbound

    I just copied your flow:

    What I missed?

    Reply
    1. Ivan Krizsan Post author

      Hi!
      I just tried the example in Mule 3.7.0 CE and, with some minor modifications, it does work.
      I modified the value-type of the maps holding the properties in DefaultTestMuleMessage from Object to TypedValue and in the test-class I changed MuleClient to DefaultLocalMuleClient.
      Make sure that the path-attribute of the inbound VM endpoint is set to “vmInbound” without quotes.
      Good luck!

      Reply
  2. amit ghorpade

    good article.
    I have a question – I got a one flow which uses http.query.params values in it and performs some business logic.
    Now When i am writing Munit test case for this flow , how I can pass http.query.params to this flow. I tried with Set Message component in Munit but no luck.

    Reply
  3. Ivan Krizsan Post author

    Hi Amit!
    I belive this is the correct way to do it:
    <munit:test name="myMunitTest" description="Test">
    <munit:set payload="Test payload">
    <munit:inbound-properties>
    <munit:inbound-property key="http.query.params" value="#[['key1' : 'value1', 'key2' : 'value2']]"/>
    </munit:inbound-properties>
    </munit:set>
    <flow-ref name="httpFlow" />
    </munit:test>

    If you use <set-property> in the MUnit test, your properties will end up in the outbound scope, while they should be in the inbound message property scope.
    Happy coding!

    Reply
  4. Siva

    good article.
    I have a question –
    I have one java class and I get Url path as like follows:
    urlPath = eventContext.getMessage().getInboundProperty(“http.request.path”);
    How can pass that value from Junit testing class.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *