Test Domain-Based Applications | MuleSoft Documentation
# Test Domain-Based Applications
Anypoint Studio 
MUnit 2.x enables you to write MUnit test suites for your Mule applications that share their resources with a Mule domain, without you performing any additional configuration. To understand how this works, it is helpful to consider a specific scenario populated with actual values, and then use those values in steps that illustrate how to write such a test.
## 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 of the Example 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
  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
```
<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.