Test MUnit Domain-Based Applications

Anypoint Studio

Test Mule applications that share resources with a Mule domain using MUnit, without additional configuration. Follow a step-by-step example using a domain-based HTTP listener application to see how MUnit resolves shared global configurations automatically.

Example Domain-Based Mule Application to Be Tested

Consider a Mule domain called domain-config that defines a global configuration for the HTTP listeners of all the Mule applications within it:

Studio Visual Editor

XML Editor

Mule domain

<domain:mule-domain ...>

<http:listener-config name="HTTP_Listener_config_domain" basePath="/" >
  <http:listener-connection host="0.0.0.0" port="8081" />
</http:listener-config>


</domain:mule-domain>

Mule domain pom.xml file

<groupId>com.mycompany</groupId>
<artifactId>domain-config</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>mule-domain</packaging>
<name>domain-config</name>

Consider also a basic Mule application that returns the path being pinged:

Studio Visual Editor

Note that this application does not define a HTTP listener global configuration because it inherits it from its Mule domain (HTTP_Listener_config_domain).

XML Editor

<mule ...>

  <flow name="application-aFlow">
        <http:listener  config-ref="HTTP_Listener_config_domain" path="/api"/>
        <set-payload value='#["You reached " ++ message.attributes.listenerPath]'/>
  </flow>

</mule>

Note that this application does not define an http:listener-config global element because it inherits it from its Mule domain (HTTP_Listener_config_domain). The application declares the domain dependency in its pom.xml file:

<dependencies>
...
  <dependency>
    <groupId>com.mycompany</groupId>
    <artifactId>domain-config</artifactId>
    <version>1.0.0</version>
    <classifier>mule-domain</classifier>
    <scope>provided</scope>
  </dependency>
...
</dependencies>

Write an MUnit Test for a Domain-Based Application

Because the Mule domain is a dependency of the Mule application, MUnit can start the Mule domain to retrieve the necessary global elements configuration for the application that it’s testing.

Assume an MUnit test to validate that the path being pinged is indeed the expected /api path:

Studio Visual Editor

Inside the execution scope, an HTTP requester sends a GET request to your application’s endpoint.
Inside the validation scope, set up an Assert Equals` processor to assert the response from the execution scope against your expected response.
To compare the response against the expected text, you must convert the payload to plain text.

XML Editor

<mule ...>

  <munit:config name="application-a-test-suite.xml" />

  <http:request-config name="HTTP_Request_configuration" basePath="/api">
    <http:request-connection host="0.0.0.0" port="8081" />
  </http:request-config>

  <munit:test name="application-a-test-suite-application-aFlowTest" description="Test to validate the path being called">

  <munit:enable-flow-sources >
    <munit:enable-flow-source value="application-aFlow" />
  </munit:enable-flow-sources>

  <munit:execution>
    <http:request config-ref="HTTP_Request_configuration" method="GET"/> (1)
  </munit:execution>

  <munit:validation>
    <munit-tools:assert-equals (2)
        actual="#[output text/plain --- payload]" (3)
        expected='#["You reached /api"]'/>
  </munit:validation>

</munit:test>

Inside the execution scope, an HTTP requester sends a GET request to your application’s endpoint.
Inside the validation scope, you decide to set up an assert-equals processor to assert the response from the execution scope against your expected response.
To compare the response against the expected text, you must convert the payload to plain text.