---
schema_version: "1"
id: 7533284afaed1f0c7468605b2b461fadedfb2ce7c50fd414fa5ee42e6b523b96
title: Test MUnit Domain-Based Applications
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/munit/latest/domain-based-application-cookbook.md
canonical_url: https://docs.mulesoft.com/munit/latest/domain-based-application-cookbook
source_site: docs.mulesoft.com
content_type: documentation
content_hash: ff576842ea024b66c68b72821e81852c3c71eecaa3241aedd9b8b6195fa9b45d
description: MuleSoft Documentation Site
release: "3.7"
latest: true
---
---
product: MUnit
version: 3.7
is-latest-version: true
---

# Test MUnit Domain-Based Applications

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")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

![domain munit example](/mulesoft/current/en-us/munit/latest/_images/domain-munit-example.png)

##### XML Editor

Mule domain

```XML
<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

```XML
<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

![mule app domain listener](/mulesoft/current/en-us/munit/latest/_images/mule-app-domain-listener.png)

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

![mule app domain set payload](/mulesoft/current/en-us/munit/latest/_images/mule-app-domain-set-payload.png)

##### XML Editor

```XML
<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:

```XML
<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

![munit domain sample](/mulesoft/current/en-us/munit/latest/_images/munit-domain-sample.png)

1.  Inside the `execution` scope, an HTTP requester sends a `GET` request to your application’s
    endpoint.

2.  Inside the `validation` scope, set up an Assert Equals\` processor to assert the response from
    the `execution` scope against your expected response.

3.  To compare the response against the expected text, you must convert the payload to plain text.

##### XML Editor

```XML
<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>
```

1.  Inside the `execution` scope, an HTTP requester sends a `GET` request to your application’s
    endpoint.

2.  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.

3.  To compare the response against the expected text, you must convert the payload to plain text.