MUnit Domain Support
Mule allows you to define connectors and libraries in a Mule Domain, to which you can deploy different Mule applications.
These domain based applications can share the resources configured in the domain to which they were deployed.
With Domain Support, MUnit allows you to test applications that run referencing a Mule Domain.
MUnit Domain Support in Anypoint Studio is available since Anypoint Studio 6.1 (which ships with MUnit Studio Plugin 1.3).
MUnit support for domain based applications is designed to require the minimum change of code from your end to implement it. However, if your Mule application depends on a Mule Domain, there are a few considerations to take into account based on the characteristics of your application and domain, for example, if such projects are Mavenized.
Regardless of whether your application is Maven based, when working in Anypoint Studio your Mule Domain must always be part of your workspace.
Domain Support in MUnit for non mavenized projects works without the need of applying any extra configurations.
When running a test for a non mavenized project in Studio 6.0.1, MUnit searches your domain settings and checks for an existing configuration.
The following log example shows up every time you run an MUnit test from Studio 6.0.1:
INFO 2016-06-09 15:51:28,253 [main] org.mule.munit.runner.domain.MunitDomainContextBuilder: Loading mule-deploy.properties ...
When working with mavenized applications, there are a couple of considerations to take into account before running the test:
The folder in your workspace containing your Mule project (regardless of whether it’s a Mule application or a Mule domain) must have the same name as the artifact ID defined in your pom file.
If your mule project’s artifact Id is:
Then, the folder in your Studio workspace must be named
This is case sensitive. If your folder is named
Mule-Project, MUnit won’t recognize your project.
The domain is a mavenizable artifact and you can mavenize it directly from Studio.
If you are working on an application and choose to mavenize it, Mule checks if its associated domain is also mavenized. If not, it will prompt you to mavenize it as well.
Mavenizing your Mule application and your Mule Domain allows you to expose both resources as dependencies for other Maven projects.
Remember that when you mavenize your domain, you need to install it in a Maven repository. Note that building the domain and the application for testing in the same execution (for example,
mvn clean test -pl 'mydomain,myapp'`) will not work.
When working with Maven, you need to handle domains and Mule apps as regular dependencies.
When mavenizing your Mule application, Studio automatically adds your mavenized domain to your application’s
If your Mule Domain project looks like this:
<modelVersion>4.0.0</modelVersion> <groupId>com.mulesoft</groupId> <artifactId>domain-project</artifactId> <packaging>mule-domain</packaging> <version>1.0.0-SNAPSHOT</version> <name>Domain domain-project Project</name>
Then your dependency in your Mule application should look like this:
<dependency> <groupId>com.mulesoft</groupId> <artifactId>domain-project</artifactId> <version>1.0.0-SNAPSHOT</version> <scope>test</scope> <type>zip</type> </dependency>
Remember to keep the