# mulesoft MUnit - Full Documentation

<!-- document id=81e4008fec195c6ce95ff56ad59e9d42e46334fd059af04717be457dfb8b54db url=/mulesoft/current/en-us/munit/2.3/assertion-equals-processor.md -->

---
product: MUnit
version: 2.3
---

# Assert Equals

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

The Assert Equals processor allows you to run assertions in order to validate the state of a Mule
Event’s content. This processor can be used to validate the Mule Event after the production code
runs.

For example, to assert that a payload is equal to a certain value, you can configure the
Assert-Equals processor the following way:

```xml
<munit-tools:assert-equals
  actual="#[payload]"
  expected="#[2]"
  message="The payload should be 2"/>
```

If the `expected` attribute is a String, you can specify the literal value without requiring an
expression.

```xml
<munit-tools:assert-equals
  actual="#[payload]"
  expected="Example"
  message="The payload should be 'Example'"/>
```

If this assertion fails, the processor throws a `java.lang.AssertionError`.

<!-- document id=87116e23eba5bc31a338ec44dd7b9ea34c93a14335337662c2d9a5bdf124e718 url=/mulesoft/current/en-us/munit/3.6/assertion-equals-processor.md -->

---
product: MUnit
version: 3.6
---

# Assert Equals

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The Assert Equals processor allows you to run assertions in order to validate the state of a Mule
Event’s content. This processor can be used to validate the Mule Event after the production code
runs.

For example, to assert that a payload is equal to a certain value, you can configure the
Assert-Equals processor the following way:

```xml
<munit-tools:assert-equals
  actual="#[payload]"
  expected="#[2]"
  message="The payload should be 2"/>
```

If the `expected` attribute is a String, you can specify the literal value without requiring an
expression.

```xml
<munit-tools:assert-equals
  actual="#[payload]"
  expected="Example"
  message="The payload should be 'Example'"/>
```

If this assertion fails, the processor throws a `java.lang.AssertionError`.

<!-- document id=b8ee57796685db7fd106c631205a26eaf3771498faef5033e576cdec2f378ecc url=/mulesoft/current/en-us/munit/2.3/assertion-expression-processor.md -->

---
product: MUnit
version: 2.3
---

# Assert Expression

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

The Assert Expression processor allows you evaluate a Dataweave expression that asserts the state of
a Mule Event’s content. This processor can be used to validate the Mule Event after the production
code runs, using the [DataWeave Assertions Library](https://docs.mulesoft.com/munit/2.3/dataweave-assertions-library).

For example, to assert that a payload is equal to a certain value, you can configure the
Assert-Expression processor using the equalTo() matcher.

```xml
<munit-tools:assert>
    <munit-tools:that>#[ import * from dw::test::Asserts ---
        payload must equalTo('example') ]
    </munit-tools:that>
</munit-tools:assert>
```

## Perform Complex Assertions

The DW assertions library allows you to assert the state of the Mule Event’s content in a deeper
way.

```xml
<munit-tools:assert>
    <munit-tools:that>#[ import * from dw::test::Asserts ---
        vars.attributes must [beObject(), $.statusCode must equalTo(200), $.method must equalTo('GET')] ]
    </munit-tools:that>
</munit-tools:assert>
```

## Create your own Matcher

To create your own matcher, you can add DW files to your `src/test/resources` folder. For example, a
file called `MyMatcher.dwl` with the following content:

```dataweave
import * from dw::test::Asserts

fun beEven(): Matcher<Number> =
     (actual:Number) -> do {
         var matchesEven = (actual mod 2) == 0
         ---
         {
             matches: matchesEven,
             description: {expected: " to be an even number.", actual: write(actual) as String}
         }
     }
```

And then use it in your Assert-Expression processor:

```xml
<munit-tools:assert>
    <munit-tools:that>#[ import * from dw::test::Asserts ---
        payload must MyMatcher::beEven() ]
    </munit-tools:that>
</munit-tools:assert>
```

If this assertion fails, the processor throws a `java.lang.AssertionError`.

> [!WARNING] Matchers from the `dw::test::Asserts` library are not compatible with the `MunitTools`
> matchers. You can’t use `dw::test::Asserts` with the Assert-That processor, and you can’t use
> `MunitTools` matchers with the Assert-Expression processor.

<!-- document id=0ecce54ca3b0c3ffcd09554524a09e6c564477eddaeafa4eb4c8f05c4faa6328 url=/mulesoft/current/en-us/munit/3.6/assertion-expression-processor.md -->

---
product: MUnit
version: 3.6
---

# Assert Expression

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The Assert Expression processor allows you evaluate a Dataweave expression that asserts the state of
a Mule Event’s content. This processor can be used to validate the Mule Event after the production
code runs, using the [DataWeave Assertions Library](https://docs.mulesoft.com/munit/3.6/dataweave-assertions-library).

For example, to assert that a payload is equal to a certain value, you can configure the
Assert-Expression processor using the equalTo() matcher.

```xml
<munit-tools:assert>
    <munit-tools:that>#[ import * from dw::test::Asserts ---
        payload must equalTo('example') ]
    </munit-tools:that>
</munit-tools:assert>
```

## Perform Complex Assertions

The DW assertions library allows you to assert the state of the Mule Event’s content in a deeper
way.

```xml
<munit-tools:assert>
    <munit-tools:that>#[ import * from dw::test::Asserts ---
        vars.attributes must [beObject(), $.statusCode must equalTo(200), $.method must equalTo('GET')] ]
    </munit-tools:that>
</munit-tools:assert>
```

## Create your own Matcher

To create your own matcher, you can add DW files to your `src/test/resources` folder. For example, a
file called `MyMatcher.dwl` with the following content:

```dataweave
import * from dw::test::Asserts

fun beEven(): Matcher<Number> =
     (actual:Number) -> do {
         var matchesEven = (actual mod 2) == 0
         ---
         {
             matches: matchesEven,
             description: {expected: " to be an even number.", actual: write(actual) as String}
         }
     }
```

And then use it in your Assert-Expression processor:

```xml
<munit-tools:assert>
    <munit-tools:that>#[ import * from dw::test::Asserts ---
        payload must MyMatcher::beEven() ]
    </munit-tools:that>
</munit-tools:assert>
```

If this assertion fails, the processor throws a `java.lang.AssertionError`.

> [!WARNING] Matchers from the `dw::test::Asserts` library are not compatible with the `MunitTools`
> matchers. You can’t use `dw::test::Asserts` with the Assert-That processor, and you can’t use
> `MunitTools` matchers with the Assert-Expression processor.

<!-- document id=a5d4a99a65486ee4ca6ff2f0372acf036ad6628354403648f81c23b5a068f8d2 url=/mulesoft/current/en-us/munit/2.3/assertion-event-processor.md -->

---
product: MUnit
version: 2.3
keywords: mule, esb, tests, qa, quality assurance, verify, functional testing, unit testing, stress testing
---

# Assert That Event Processor

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

The Assert That event processor allows you to run assertions to validate the state of a Mule event’s
content. You can use the Assert That processor to validate the Mule event after the production code
runs.

The Assert That processor uses a set of DataWeave functions called `MUnit matchers` to define the
assertion conditions for any value in an expression.

For example, to assert that a payload is equal to a certain value, configure the Assert That
processor using the `equalTo()` matcher.

```xml
<munit-tools:assert-that
  expression="#[payload]"
  is="#[MunitTools::equalTo('example')]"
  message="The payload should be ‘example’"/>
```

Or you can also check if the payload is null using the `nullValue()` matcher.

```xml
<munit-tools:assert-that
  expression="#[payload]"
  is="#[MunitTools::nullValue()]"
  message="The payload should be null"/>
```

See [MUnit Matchers](https://docs.mulesoft.com/munit/2.3/munit-matchers) for more information.

If these assertion fails, the processor throws a `java.lang.AssertionError`.

## See Also

- [MUnit Matchers](https://docs.mulesoft.com/munit/2.3/munit-matchers)

<!-- document id=2298ab3d5330c6fd31f5b956fa71954f78355d194a6c9b06877d8a82142106fd url=/mulesoft/current/en-us/munit/3.6/assertion-event-processor.md -->

---
product: MUnit
version: 3.6
keywords: mule, esb, tests, qa, quality assurance, verify, functional testing, unit testing, stress testing
---

# Assert That Event Processor

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The Assert That event processor allows you to run assertions to validate the state of a Mule event’s
content. You can use the Assert That processor to validate the Mule event after the production code
runs.

The Assert That processor uses a set of DataWeave functions called `MUnit matchers` to define the
assertion conditions for any value in an expression.

For example, to assert that a payload is equal to a certain value, configure the Assert That
processor using the `equalTo()` matcher.

```xml
<munit-tools:assert-that
  expression="#[payload]"
  is="#[MunitTools::equalTo('example')]"
  message="The payload should be ‘example’"/>
```

Or you can also check if the payload is null using the `nullValue()` matcher.

```xml
<munit-tools:assert-that
  expression="#[payload]"
  is="#[MunitTools::nullValue()]"
  message="The payload should be null"/>
```

See [MUnit Matchers](https://docs.mulesoft.com/munit/3.6/munit-matchers) for more information.

If these assertion fails, the processor throws a `java.lang.AssertionError`.

## See Also

- [MUnit Matchers](https://docs.mulesoft.com/munit/3.6/munit-matchers)

<!-- document id=b931475cbdd1143e5b4fb6ff86c5788d4c76adb96bfb9db62b5f35cef334160f url=/mulesoft/current/en-us/munit/2.3/before-after-scopes-reference.md -->

---
product: MUnit
version: 2.3
---

# Before and After Scopes

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

## Before Suite Scope

The MUnit Before Suite contains code that is meant to be executed before the whole suite. The Before
Suite has one execution rule: Run before all the tests, just once.

For example, suppose you have an MUnit Test Suite file with four tests. The code inside an MUnit
Before Suite runs just once, before your four tests.

> [!NOTE] You can only use one Before Suite scope per MUnit test suite.

Before Suite example

```xml
<munit:before-suite name="before-suite" description="Executes a before suite">
  <!-- some mule code here -->
</munit:before-suite >

<munit:test name="munit.test" description="Test">
  <!-- some more mule code here -->
</munit:test>
```

Note that the `before-suite` is located outside the MUnit test. One instance in which the MUnit
Before Suite is useful is when you need to set up a test environment before all tests run.

When you place a before-suite in the Anypoint Studio canvas, the scope locates outside the MUnit
test.

## After Suite Scope

The MUnit After Suite is a scope. It can contain code that is meant to be executed after the whole
suite. The After suite has one execution rule: Run after all the tests, just once.

For instance, let’s suppose you have an MUnit Test Suite File with four tests. The code inside an
MUnit After Suite, runs just once, after all your tests.

> [!NOTE] You can only use one After Suite scope per MUnit test suite.

After Suite example

```xml
<munit:before-suite name="before.suite" description="A description">
  <!-- some mule code here -->
</munit:before-suite >

<munit:test name="munit.test" description="Test">
  <!-- some more mule code here -->
</munit:test>

<munit:after-suite  name="after.suite" description="A description">
  <!-- some Mule code here -->
</munit:after-suite >
```

Note that the after-suite is located outside the MUnit test. One instance in which the MUnit After
Suite is useful is when you need to tear down a test environment after the whole test runs.

When you place an after-suite in the Anypoint Studio canvas, the scope locates outside the MUnit
test.

## Before Test Scope

The MUnit Before Test Scope contains code that is meant to be executed before each test. Each Before
Test scope follows the same execution rule: Run before each test.

For instance, let’s suppose you have an MUnit Test Suite file with four tests. The code inside an
MUnit Before test runs before each of your four tests; it runs four times.

> [!NOTE] You can only use one Before Test scope per MUnit test suite.

Before Test example

```xml
<munit:before-test name="before.test" description="A description">
  <!-- some mule code here -->
</munit:before-test>

<munit:test name="munit.test" description="Test">
  <!-- some more mule code here -->
</munit:test>
```

Note that the `before.test` is located outside the MUnit test. One instance in which the MUnit
Before Test is useful is when you need to set up a test environment before each test run, like
creating a file or setting a variable that will be consumed in each test.

When you place an before-test in the Anypoint Studio canvas, the scope locates outside the MUnit
test.

## After Test Scope

The MUnit After Test Scope contains code that is meant to be executed after each test. Each After
Test scope follows the same execution rule: Run after each test.

For instance, let’s suppose you have an MUnit Test Suite file with four tests. The code inside an
MUnit After Test runs after each of your four tests; it runs four times.

> [!NOTE] You can only use one After Test scope per MUnit test suite.

After Test example

```xml
<munit:before-test name="before.test" description="A description">
  <!-- some mule code here -->
</munit:before-test>

<munit:test name="munit.test" description="Test">
  <!-- some more mule code here -->
</munit:test>

<munit:after-test  name="after.test" description="A description">
  <!-- some mule code here -->
</munit:after-test>
```

Note that the `after.test` is located outside the MUnit test. One instance in which the MUnit After
test is useful is when you need to tear down a test environment after the whole test runs.

When you place an after-test in the Anypoint Studio canvas, the scope locates outside the MUnit
test.

## Before Suite Reference

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>name</code></p></td><td><p>Defines the name of the Before suite. The name must be unique inside the suite.</p></td></tr><tr><td><p><code>description</code></p></td><td><p>Describes the actions performed.</p></td></tr></tbody></table>

## After Suite Reference

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>name</code></p></td><td><p>Defines the name of the After suite. The name must be unique inside the suite.</p></td></tr><tr><td><p><code>description</code></p></td><td><p>Describes the actions performed.</p></td></tr></tbody></table>

## Before Test Reference

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>name</code></p></td><td><p>Defines the name of the Before test. The name must be unique inside the suite.</p></td></tr><tr><td><p><code>description</code></p></td><td><p>Describes the actions performed.</p></td></tr></tbody></table>

## After Test Reference

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>name</code></p></td><td><p>Defines the name of the After test. The name must be unique inside the suite.</p></td></tr><tr><td><p><code>description</code></p></td><td><p>Describes the actions performed.</p></td></tr></tbody></table>

<!-- document id=bb3570da95e112b83b0eda56639d307a78d804bb3b94d1127fdd846acca84eca url=/mulesoft/current/en-us/munit/3.6/before-after-scopes-reference.md -->

---
product: MUnit
version: 3.6
---

# Before and After Scopes

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

## Before Suite Scope

The MUnit Before Suite contains code that is meant to be executed before the whole suite. The Before
Suite has one execution rule: Run before all the tests, just once.

For example, suppose you have an MUnit Test Suite file with four tests. The code inside an MUnit
Before Suite runs just once, before your four tests.

> [!NOTE] You can only use one Before Suite scope per MUnit test suite.

Before Suite example

```xml
<munit:before-suite name="before-suite" description="Executes a before suite">
  <!-- some mule code here -->
</munit:before-suite >

<munit:test name="munit.test" description="Test">
  <!-- some more mule code here -->
</munit:test>
```

Note that the `before-suite` is located outside the MUnit test. One instance in which the MUnit
Before Suite is useful is when you need to set up a test environment before all tests run.

When you place a before-suite in the Anypoint Studio canvas, the scope locates outside the MUnit
test.

## After Suite Scope

The MUnit After Suite is a scope. It can contain code that is meant to be executed after the whole
suite. The After suite has one execution rule: Run after all the tests, just once.

For instance, let’s suppose you have an MUnit Test Suite File with four tests. The code inside an
MUnit After Suite, runs just once, after all your tests.

> [!NOTE] You can only use one After Suite scope per MUnit test suite.

After Suite example

```xml
<munit:before-suite name="before.suite" description="A description">
  <!-- some mule code here -->
</munit:before-suite >

<munit:test name="munit.test" description="Test">
  <!-- some more mule code here -->
</munit:test>

<munit:after-suite  name="after.suite" description="A description">
  <!-- some Mule code here -->
</munit:after-suite >
```

Note that the after-suite is located outside the MUnit test. One instance in which the MUnit After
Suite is useful is when you need to tear down a test environment after the whole test runs.

When you place an after-suite in the Anypoint Studio canvas, the scope locates outside the MUnit
test.

## Before Test Scope

The MUnit Before Test Scope contains code that is meant to be executed before each test. Each Before
Test scope follows the same execution rule: Run before each test.

For instance, let’s suppose you have an MUnit Test Suite file with four tests. The code inside an
MUnit Before test runs before each of your four tests; it runs four times.

> [!NOTE] You can only use one Before Test scope per MUnit test suite.

Before Test example

```xml
<munit:before-test name="before.test" description="A description">
  <!-- some mule code here -->
</munit:before-test>

<munit:test name="munit.test" description="Test">
  <!-- some more mule code here -->
</munit:test>
```

Note that the `before.test` is located outside the MUnit test. One instance in which the MUnit
Before Test is useful is when you need to set up a test environment before each test run, like
creating a file or setting a variable that will be consumed in each test.

When you place an before-test in the Anypoint Studio canvas, the scope locates outside the MUnit
test.

## After Test Scope

The MUnit After Test Scope contains code that is meant to be executed after each test. Each After
Test scope follows the same execution rule: Run after each test.

For instance, let’s suppose you have an MUnit Test Suite file with four tests. The code inside an
MUnit After Test runs after each of your four tests; it runs four times.

> [!NOTE] You can only use one After Test scope per MUnit test suite.

After Test example

```xml
<munit:before-test name="before.test" description="A description">
  <!-- some mule code here -->
</munit:before-test>

<munit:test name="munit.test" description="Test">
  <!-- some more mule code here -->
</munit:test>

<munit:after-test  name="after.test" description="A description">
  <!-- some mule code here -->
</munit:after-test>
```

Note that the `after.test` is located outside the MUnit test. One instance in which the MUnit After
test is useful is when you need to tear down a test environment after the whole test runs.

When you place an after-test in the Anypoint Studio canvas, the scope locates outside the MUnit
test.

## Before Suite Reference

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>name</code></p></td><td><p>Defines the name of the Before suite. The name must be unique inside the suite.</p></td></tr><tr><td><p><code>description</code></p></td><td><p>Describes the actions performed.</p></td></tr></tbody></table>

## After Suite Reference

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>name</code></p></td><td><p>Defines the name of the After suite. The name must be unique inside the suite.</p></td></tr><tr><td><p><code>description</code></p></td><td><p>Describes the actions performed.</p></td></tr></tbody></table>

## Before Test Reference

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>name</code></p></td><td><p>Defines the name of the Before test. The name must be unique inside the suite.</p></td></tr><tr><td><p><code>description</code></p></td><td><p>Describes the actions performed.</p></td></tr></tbody></table>

## After Test Reference

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>name</code></p></td><td><p>Defines the name of the After test. The name must be unique inside the suite.</p></td></tr><tr><td><p><code>description</code></p></td><td><p>Describes the actions performed.</p></td></tr></tbody></table>

<!-- document id=d5104d82f2136359bbce28164b04d8913ba4105927deb39d33aeaf67d35f7ab5 url=/mulesoft/current/en-us/munit/2.3/comparable-matchers-reference.md -->

---
product: MUnit
version: 2.3
---

# Comparable Matchers Reference

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

> [!NOTE] `Comparable` is a DataWeave type that represents all the types that can be compared to
> each other.  
> Allowed primitives are String, Number, Boolean, DateTime, LocalDateTime, LocalTime, Time, and
> TimeZone that you can pass any primitive value such as an integer or a date.

## greaterThan(Comparable)

Checks that the expression is greater than the specified value.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::greaterThan(|2017-08-09|)]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::greaterThan(20)]"/>
```

## greaterThanOrEqualTo(Comparable)

Checks that the expression is greater than or equal to the specified value.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::greaterThanOrEqualTo(20)]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::greaterThanOrEqualTo(|2017-08-09|)]"/>
```

## lessThan(Comparable)

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::lessThan(20)]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::lessThan(|2017-08-09|)]"/>
```

## lessThanOrEqualTo(Comparable)

Checks that the expression is less than or equal to the specified value.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::lessThanOrEqualTo(20)]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::lessThanOrEqualTo(|2017-08-09|)]"/>
```

## closeTo(Number, Number)

Checks that the expression is close to the first number, using the second number as a delta value.  
In other words, checks that the expression belongs to the range defined by the first number +/- the
second number.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::closeTo(1, 0.01)]"/>

<!--
  This evaluates if the expression is between 0.99 (1 - 0.01) and 1.01 (1 + 0.01)
-->
```

## equalTo(Object)

Checks that the expression is equal to a specific value.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::equalTo(0)]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::equalTo('example')]"/>
```

This matcher also accepts Dataweave objects.

Example

```xml
<munit-tools:assert-that
expression="#[{example1: 1 , example2: 2}]"
is="#[MunitTools::equalTo({example1: 1 , example2: 2})]"/>
```

The matcher validates that the keys and their respective values are the same.  
The order in the matcher must be the same as the one in the expression or the assertion fails.

Example

```xml
<munit-tools:assert-that
expression="#[{example1: 1 , example2: 2}]"
is="#[MunitTools::equalTo({example2: 2 , example1: 1})]"/>

<!-- This assertion fails -->
```

Example

```xml
<munit-tools:assert-that
expression="#[[1, 2, 3]]"
is="#[MunitTools::equalTo([3, 2, 1])]"/>

<!-- This assertion fails -->
```

## See Also

- [DataWeave Comparable Type](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_comparable)

- [MUnit Matchers](https://docs.mulesoft.com/munit/2.3/munit-matchers)

- [Core Matchers Reference](https://docs.mulesoft.com/munit/2.3/core-matchers-reference)

- [String Matchers Reference](https://docs.mulesoft.com/munit/2.3/string-matchers-reference)

- [Iterable and Map Matchers Reference](https://docs.mulesoft.com/munit/2.3/iterable-map-matchers-reference)

<!-- document id=b001c51b675f61b9067f19205cb9af49af7b8aa4cec62b940d9634e142ef0079 url=/mulesoft/current/en-us/munit/3.6/comparable-matchers-reference.md -->

---
product: MUnit
version: 3.6
---

# Comparable Matchers Reference

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

> [!NOTE] `Comparable` is a DataWeave type that represents all the types that can be compared to
> each other.  
> Allowed primitives are String, Number, Boolean, DateTime, LocalDateTime, LocalTime, Time, and
> TimeZone that you can pass any primitive value such as an integer or a date.

## greaterThan(Comparable)

Checks that the expression is greater than the specified value.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::greaterThan(|2017-08-09|)]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::greaterThan(20)]"/>
```

## greaterThanOrEqualTo(Comparable)

Checks that the expression is greater than or equal to the specified value.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::greaterThanOrEqualTo(20)]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::greaterThanOrEqualTo(|2017-08-09|)]"/>
```

## lessThan(Comparable)

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::lessThan(20)]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::lessThan(|2017-08-09|)]"/>
```

## lessThanOrEqualTo(Comparable)

Checks that the expression is less than or equal to the specified value.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::lessThanOrEqualTo(20)]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::lessThanOrEqualTo(|2017-08-09|)]"/>
```

## closeTo(Number, Number)

Checks that the expression is close to the first number, using the second number as a delta value.  
In other words, checks that the expression belongs to the range defined by the first number +/- the
second number.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::closeTo(1, 0.01)]"/>

<!--
  This evaluates if the expression is between 0.99 (1 - 0.01) and 1.01 (1 + 0.01)
-->
```

## equalTo(Object)

Checks that the expression is equal to a specific value.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::equalTo(0)]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::equalTo('example')]"/>
```

This matcher also accepts Dataweave objects.

Example

```xml
<munit-tools:assert-that
expression="#[{example1: 1 , example2: 2}]"
is="#[MunitTools::equalTo({example1: 1 , example2: 2})]"/>
```

The matcher validates that the keys and their respective values are the same.  
The order in the matcher must be the same as the one in the expression or the assertion fails.

Example

```xml
<munit-tools:assert-that
expression="#[{example1: 1 , example2: 2}]"
is="#[MunitTools::equalTo({example2: 2 , example1: 1})]"/>

<!-- This assertion fails -->
```

Example

```xml
<munit-tools:assert-that
expression="#[[1, 2, 3]]"
is="#[MunitTools::equalTo([3, 2, 1])]"/>

<!-- This assertion fails -->
```

## See Also

- [DataWeave Comparable Type](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_comparable)

- [MUnit Matchers](https://docs.mulesoft.com/munit/3.6/munit-matchers)

- [Core Matchers Reference](https://docs.mulesoft.com/munit/3.6/core-matchers-reference)

- [String Matchers Reference](https://docs.mulesoft.com/munit/3.6/string-matchers-reference)

- [Iterable and Map Matchers Reference](https://docs.mulesoft.com/munit/3.6/iterable-map-matchers-reference)

<!-- document id=2be3943d30d6fe3da741bd74e5913f28999b041f220f9e44cc549798a23b1135 url=/mulesoft/current/en-us/munit/latest/coverage-maven-concept.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# Configure MUnit Coverage in Maven

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

Configure MUnit coverage reports in Maven by adding the munit-maven-plugin to your pom.xml and
enabling the coverage-report goal. Coverage reports are generated during the Maven site lifecycle
and are not available when running tests from Anypoint Code Builder or Anypoint Studio.

MUnit Coverage - Sample Maven configuration

```xml
<plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <version>${munit.version}</version>

    <executions>
        <execution>
            <id>test</id>
            <phase>test</phase>
            <goals>
                <goal>test</goal>
                <goal>coverage-report</goal>
            </goals>
        </execution>
    </executions>

    <configuration>
        <coverage>
            <runCoverage>true</runCoverage>
            <failBuild>false</failBuild>

            <requiredApplicationCoverage>75</requiredApplicationCoverage>
            <requiredResourceCoverage>50</requiredResourceCoverage>
            <requiredFlowCoverage>50</requiredFlowCoverage>

            <formats>
                <format>console</format>
                <format>html</format>
            </formats>
        </coverage>
    </configuration>
</plugin>
```

## Coverage Report Types

When you enable MUnit Coverage, the console displays a summary report.

```console
===============================================================================
MUnit Coverage Summary
===============================================================================
 * Resources: 2 - Flows: 3 - Processors: 4
 * Application Coverage: 75.00%
====================================================================================
```

MUnit Coverage offers four types of reports:

- Console report  
  The console report prints in the console. It works with the summary report and shows an overview
  of the MUnit run, with a count of all resources, flows, and processors, as well as the overall
  application coverage level, and warnings and errors if any.

- HTML report  
  The HTML report shows the same information as the console report but is formatted to fit any web
  browser. It’s available in the `${application.path}/target/site/munit/coverage/` path.

- JSON report  
  The JSON report provides the same information as the HTML report but in a JSON format. It’s
  available at `${application.path}/target/site/munit/coverage/munit-coverage.json`.

- SONAR report  
  The SONAR report shows the same information as the HTML report, in a SonarQube format.

To enable the report generation, add the following configuration:

MUnit Coverage - Report Configuration

```xml
<coverage>
    <runCoverage>true</runCoverage>

    <formats>
        <format>console</format> (1)
        <format>html</format>    (2)
        <format>json</format>    (3)
        <format>sonar</format>   (4)
    </formats>
</coverage>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Console report</td></tr><tr><td><i data-value="2"></i><b>2</b></td><td>HTML report</td></tr><tr><td><i data-value="3"></i><b>3</b></td><td>JSON report</td></tr><tr><td><i data-value="4"></i><b>4</b></td><td>SONAR report</td></tr></tbody></table>

You can choose to have either none, one, or all the report types added to your configuration.

To configure, for example, the JSON report generation, add the following configuration to your
`pom.xml` file:

```xml
<coverage>
    <runCoverage>true</runCoverage>

    <formats>
        <format>json</format>
    </formats>
</coverage>
```

## Set Up a Minimum Coverage Level

One of the features of MUnit Coverage is to fail the build if a certain coverage level isn’t
reached.

MUnit Coverage handles three different levels:

- **Application**: The overall coverage of all your application.

- **Resource**: The coverage level of each Mule configuration file.

- **Flow**: The coverage of event processors in each flow.

To define the required coverage levels:

MUnit Coverage - Require Coverage

```xml
<coverage>
    <runCoverage>true</runCoverage>
    <failBuild>true</failBuild>

    <requiredApplicationCoverage>75</requiredApplicationCoverage> (1)
    <requiredResourceCoverage>50</requiredResourceCoverage>
    <requiredFlowCoverage>50</requiredFlowCoverage>
</coverage>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Each value represents a percentage.<br>If a percentage isn’t defined, it defaults to <strong>-1</strong>, which sets no requirements for said level so the build doesn’t fail due to low coverage.</td></tr></tbody></table>

If you define coverage levels but set the property `failBuild` to `false`, and then the levels
aren’t reached, a warning shows up in the MUnit Coverage summary:

```console
===============================================================================
MUnit Coverage Summary
===============================================================================
 * Resources: 2 - Flows: 3 - Processors: 4
 * Application Coverage: 75.00%

----------------------------- WARNING --------------------------------------
 * Flow: file2.xml -> file2Flow1 coverage is below defined limit. Required: 50.0% - Current: 00.00% (1)
====================================================================================
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Warning detailing which coverage level isn’t met, and where it happens.</td></tr></tbody></table>

## Ignore a Flow or a File

You can also ignore a flow or a file. This way, the ignored resource:

- Does not count as coverage data.

- Does not affect the overall number of message processors.

- Does not cause a build to fail if the flow isn’t tested or if the flow doesn’t reach coverage
  metrics.

To ignore flows and files:

MUnit Coverage - Ignore flows and files

```xml
<coverage>
    <runCoverage>true</runCoverage>
    <failBuild>true</failBuild>

    <requiredApplicationCoverage>100</requiredApplicationCoverage>
    <requiredResourceCoverage>100</requiredResourceCoverage>
    <requiredFlowCoverage>100</requiredFlowCoverage>

    <ignoreFlows>
        <ignoreFlow>flow-1</ignoreFlow>
        <ignoreFlow>flow-2</ignoreFlow>
        ...
        <ignoreFlow>flow-n</ignoreFlow>
    </ignoreFlows>

    <ignoreFiles>
        <ignoreFile>mule-config-1.xml</ignoreFile>
        <ignoreFile>mule-config-2.xml</ignoreFile>
        ...
        <ignoreFile>mule-config-n.xml</ignoreFile>
    </ignoreFiles>
</coverage>
```

## See Also

- [Coverage Report](https://docs.mulesoft.com/munit/latest/munit-coverage-report)

- [Run MUnit Coverage Reports in Anypoint Studio](https://docs.mulesoft.com/munit/latest/coverage-studio-concept).

<!-- document id=234d59cb9ba59bdcc4e19a56caab5455578ab0cd383163b65d54f523f995be1d url=/mulesoft/current/en-us/munit/latest/db-server-cookbook.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# Configure the MUnit Database Server Utility

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

Configure the MUnit Database Server utility to run MUnit tests against an in-memory database without
connecting to an external database server. Use it to test Mule flows that interact with a database
connector in an isolated and repeatable way.

If you want to test the following Mule application:

```xml
<!-- Local Database Configuration -->
<db:config name="Database_Config">
    <db:my-sql-connection host="localhost" port="1234" />
</db:config>
<!-- Properties according to the environment -->
<configuration-properties file="db.properties" />

<flow name="selectFlow" >
    <!-- Perform a query based on a value passed by a variable -->
    <db:select config-ref="${db.config}">
        <db:sql >SELECT * FROM jobtitlelookup WHERE jobtitleid = :id</db:sql>
        <db:input-parameters ><![CDATA[#[id : vars.jobid]]]></db:input-parameters>
    </db:select>
    <!-- Set two conditions depending on the query result -->
    <choice>
        <!-- If there is one or more values resulting from the query set those values as the payload -->
        <when expression="#[sizeOf(payload) > 0]">
            <set-payload value="#[payload[0].jobtitle]"/>
        </when>
        <!-- If the query throws no results, inform it in the payload  -->
        <otherwise>
            <set-payload value="#['No job title for $(vars.jobid) was found']" />
        </otherwise>
    </choice>

    <!-- Finally, pass the payload content as a Flow variable  -->
    <set-variable value="#[payload]" variableName="job" />
</flow>
```

The file `db.properties` in `src/main/resources` has the following content:

```none
db.config=Database_Config
```

You must create a test that:

- Contains a database server with a `jobtitlelookup` table.

- Provides a valid database structure for the database connector to perform its query.

- Passes a value for the `jobid` variable that Database Connector uses.

## Install the MUnit DB Server Module

1.  Look for the **MUnit Utils Database Server** module.

2.  Add the module to your project:

    ```xml
    <!-- dbserver Dependency -->
    <dependency>
        <groupId>com.mulesoft.munit.utils</groupId>
        <artifactId>munit-dbserver-module</artifactId>
        <version>2.0.2</version>
        <classifier>mule-plugin</classifier>
        <scope>test</scope>
    </dependency>
    ```

    The MUnit DB server artifact in your POM file must have the `test` scope.

3.  Add the `h2` dependency to your POM file and list it as `sharedLibrary` in `mule-maven-plugin`:

    ```xml
    <!--Third party libs-->
    <dependency>
        <groupId>com.h2database</groupId>
        <artifactId>h2</artifactId>
        <version>1.3.166</version>
    </dependency>
    ```

    ```xml
    <plugin>
        <groupId>org.mule.tools.maven</groupId>
        <artifactId>mule-maven-plugin</artifactId>
        <version>${mule.maven.plugin.version}</version>
        <extensions>true</extensions>
        <configuration>
        <sharedLibraries>
                ...
                <sharedLibrary>
                    <groupId>com.h2database</groupId>
                    <artifactId>h2</artifactId>
                </sharedLibrary>
            </sharedLibraries>
        </configuration>
    </plugin>
    ```

The **h2** dependency enhances MUnit tests by allowing the simulation of database interactions using
an in-memory, lightweight, and fast database. This setup ensures tests are both isolated and
repeatable.

> [!NOTE] The **MUnit DB Server** module is located at
> [MuleSoft Nexus repository](https://repository.mulesoft.org/nexus/content/repositories/releases/com/mulesoft/munit/utils/munit-dbserver-module/).
> The **MUnit DB Server** module version 3 and later is compatible with Java 17. Previous versions
> of this module available at Anypoint Exchange are deprecated.

## Define the MUnit DB Server

Define the database server by creating the **global-configs.xml** file and defining the MUnit DB
Server Config element.

Define the MUnit DB Server Config element as follows:

1.  Go to the `src/test/resources` directory in your project.

2.  Create a file named `jobtitlelookup.csv` containing the following values:

    ```text
    JOBTITLE,EECSALARYORHOURLY,JOBTITLEID
    Developer,10,DEV
    ```

3.  Create the **global-configs.xml** file and define the **MUnit DB Server Config** element as
    follows:

    ```xml
    <dbserver:config name="MUnit_DB_Server_Config" >
        <dbserver:connection csv="jobtitlelookup.csv" database="DATABASE_NAME" connectionStringParameters="MODE=MySQL" />
    </dbserver:config>
    ```

4.  Define the DB configuration to connect to your DB server:

    ```xml
    <db:config name="Test_Database_Config">
        <db:generic-connection url="jdbc:h2:tcp://localhost/mem:DATABASE_NAME" driverClassName="org.h2.Driver" />
    </db:config>
    ```

5.  Define the `db.properties` file in your `src/test/resources` folder that picks up your test
    database configuration:

    ```none
    db.config=Test_Database_Config
    ```

## Run the Test

After installing and configuring the DB server you can run the test:

```xml
<munit:test name="selectFlowTest" description="Test selectFlow"  >
    <munit:behavior>
        <!-- Passes a variable to value to run in the main flow. -->
        <set-variable variableName="jobid" value="DEV" />
    </munit:behavior>
    <munit:execution>
        <!-- Run the production code. -->
        <flow-ref name="db-server-docsFlow"/>
    </munit:execution>
    <munit:validation>
        <munit-tools:assert-equals actual="#[vars.job]" expected="Developer" />
    </munit:validation>
</munit:test>
```

This test validates that the query run in your production code is correct and that the DB server
returns the payload as expected.

## See Also

- [Database Util](https://docs.mulesoft.com/munit/latest/db-util)

- [Add Modules to Your Test in Anypoint Code Builder](https://docs.mulesoft.com/anypoint-code-builder/ref-acb-commands)

- [Add Modules to Your Test in Anypoint Studio](https://docs.mulesoft.com/studio/add-modules-in-studio-to)

<!-- document id=fd440cd42402220d8c5abfcdf80103946e70255d5fddee5fbb5c012007a0c979 url=/mulesoft/current/en-us/munit/latest/ftp-server-cookbook.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# Configure the MUnit FTP Server Utility

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

Configure the MUnit FTP Server utility to run MUnit tests against an in-memory FTP server without
connecting to an external FTP server. Use it to test Mule flows that interact with FTP or SFTP
connectors in an isolated environment.

If you want to test the following Mule application:

```xml
<sftp:config name="SFTP_Config">
    <sftp:connection host="${ftp.host}" port="${ftp.port}" username="${ftp.user}" password="${ftp.password}"/>
</sftp:config>

<configuration-properties file="ftp.properties" />

<flow name="listFlow">
    <sftp:list config-ref="SFTP_Config" directoryPath="."/>
    <foreach>
        <logger level="INFO" message="#[attributes.fileName]"/>
    </foreach>
</flow>
```

The `ftp.properties` in `src/main/resources` has the following content:

```none
ftp.host=localhost
ftp.port=22
ftp.user=max
ftp.password=munittest
```

The username field can’t be empty. If you don’t have a username-password pair, set the username to
`anonymous` and don’t set any password. By default, the `anonymous` attribute is set to `true`.

## Install the FTP Server

To install the FTP server:

1.  Look for the **MUnit Utils FTP Server** module.

2.  Add the module to your project:

    ```xml
    <!-- Ftp Server Dependency -->
    <dependency>
        <groupId>com.mulesoft.munit.utils</groupId>
        <artifactId>munit-ftpserver-module</artifactId>
        <version>2.0.1</version>
        <classifier>mule-plugin</classifier>
        <scope>test</scope>
    </dependency>
    ```

    The MUnit FTP server artifact in your POM file must have the `test` scope.

> [!NOTE] The **MUnit FTP Server** module is located at
> [MuleSoft Nexus repository](https://repository.mulesoft.org/nexus/content/repositories/releases/com/mulesoft/munit/utils/munit-ftpserver-module/).
> The **MUnit FTP Server** module version 3 and later is compatible with Java 17. Previous versions
> of this module available at Anypoint Exchange are deprecated.

## Define the FTP Server

To define the FTP server, change the FTP server attributes as follows:

```xml
<ftpserver:config name="MUnit_FTP_Server_Config">
    <ftpserver:connection port="${ftp.port}" username="${ftp.user}" password="${ftp.password}" secure="true" homeDir="${app.home}"/>
----
</ftpserver:config>
----
```

## Run the Test

After configuring the FTP server, you can run the test:

```xml
<munit:test name="listFlowTest" description="Test listFlow" >
    <munit:execution>
        <flow-ref name="listFlow"/>
    </munit:execution>
    <munit:validation>
        <munit-tools:assert-that expression="#[sizeOf(payload)]" is="#[MunitTools::greaterThan(0)]"/>
    </munit:validation>
</munit:test>
```

This FTP accepts any user, so you must not set up a user database or list.

## See Also

- [FTP Util](https://docs.mulesoft.com/munit/latest/ftp-util)

<!-- document id=302fbeb35e0e4de1fbb4ae66e736139d86f69cc48b4dec9d7385721ef672964d url=/mulesoft/current/en-us/munit/2.3/db-server-cookbook.md -->

---
product: MUnit
version: 2.3
---

# Configuring Database Server Utility in an MUnit Test

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

Assume that you want to test the following Mule application:

```xml
<!-- Local Database Configuration -->
<db:config name="Database_Config">
    <db:my-sql-connection host="localhost" port="1234" />
</db:config>
<!-- Properties according to the environment -->
<configuration-properties file="db.properties" />

<flow name="selectFlow" >
    <!-- Perform a query based on a value passed by a variable -->
    <db:select config-ref="${db.config}">
        <db:sql >SELECT * FROM jobtitlelookup WHERE jobtitleid = :id</db:sql>
        <db:input-parameters ><![CDATA[#[id : vars.jobid]]]></db:input-parameters>
    </db:select>
    <!-- Set two conditions depending on the query result -->
    <choice>
        <!-- If there is one or more values resulting from the query set those values as the payload -->
        <when expression="#[sizeOf(payload) > 0]">
            <set-payload value="#[payload[0].jobtitle]"/>
        </when>
        <!-- If the query throws no results, inform it in the payload  -->
        <otherwise>
            <set-payload value="#['No job title for $(vars.jobid) was found']" />
        </otherwise>
    </choice>

    <!-- Finally, pass the payload content as a Flow variable  -->
    <set-variable value="#[payload]" variableName="job" />
</flow>
```

The file `db.properties` in `src/main/resources` has the following content:

```none
db.config=Database_Config
```

You need to create a test that: \* Contains a database server with a `jobtitlelookup` table. \*
Provides a valid database structure for the database connector to perform its query. \* Passes a
value for the `jobid` variable that Database Connector uses.

## Install the MUnit DB Server Module

1.  From Anypoint Studio, go to the **Mule Palette** view and locate **Search in Exchange…​**.

2.  In the search bar, look for **MUnit Utils Database Server** and add the module to your project:

    ```xml
    <!-- dbserver Dependency -->
    <dependency>
        <groupId>com.mulesoft.munit.utils</groupId>
        <artifactId>munit-dbserver-module</artifactId>
        <version>2.0.2</version>
        <classifier>mule-plugin</classifier>
        <scope>test</scope>
    </dependency>
    ```

    The MUnit DB server artifact in your POM file must have the `test` scope.

3.  Add the `h2` dependency to your POM file and list it as `sharedLibrary` in `mule-maven-plugin`:

    ```xml
    <!--Third party libs-->
    <dependency>
        <groupId>com.h2database</groupId>
        <artifactId>h2</artifactId>
        <version>1.3.166</version>
    </dependency>
    ```

    ```xml
    <plugin>
        <groupId>org.mule.tools.maven</groupId>
        <artifactId>mule-maven-plugin</artifactId>
        <version>${mule.maven.plugin.version}</version>
        <extensions>true</extensions>
        <configuration>
        <sharedLibraries>
                ...
                <sharedLibrary>
                    <groupId>com.h2database</groupId>
                    <artifactId>h2</artifactId>
                </sharedLibrary>
            </sharedLibraries>
        </configuration>
    </plugin>
    ```

## Define the MUnit DB Server

Define the database server using the **MUnit DB Server Config** from the **Global Elements** in your
canvas.

For this example, define the DB structure and content using a CSV file:

1.  Go to the `src/test/resources` directory in your project.

2.  Create a file named `jobtitlelookup.csv` containing the following values:

    ```text
    JOBTITLE,EECSALARYORHOURLY,JOBTITLEID
    Developer,10,DEV
    ```

3.  Navigate to the **Global Elements** tab and select the **MUnit DB Server Config** element.

4.  Click **Edit** and complete the fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Name</th><th><code>MUnit_DB_Server_Config</code></th></tr></thead><tbody><tr><td><div><div><p>CSV</p></div></div></td><td><div><div><p><code>jobtitlelookup.csv</code></p></div></div></td></tr><tr><td><div><div><p>Database</p></div></div></td><td><div><div><p><code>DATABASE_NAME</code></p></div></div></td></tr><tr><td><div><div><p>Connection string parameters</p></div></div></td><td><div><div><p><code>MODE=MySQL</code></p></div></div></td></tr></tbody></table>

    ```xml
    <dbserver:config name="MUnit_DB_Server_Config" >
        <dbserver:connection csv="jobtitlelookup.csv" database="DATABASE_NAME" connectionStringParameters="MODE=MySQL" />
    </dbserver:config>
    ```

5.  Define the DB configuration to connect to your DB server:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Name</th><th><code>Test_Database_Config</code></th></tr></thead><tbody><tr><td><div><div><p>Connection</p></div></div></td><td><div><div><p><code>Generic connection</code></p></div></div></td></tr><tr><td><div><div><p>URL</p></div></div></td><td><div><div><p><code>jdbc:h2:tcp://localhost/mem:DATABASE_NAME</code></p></div></div></td></tr><tr><td><div><div><p>Driver class name</p></div></div></td><td><div><div><p><code>org.h2.Driver</code></p></div></div></td></tr></tbody></table>

    ```xml
    <db:config name="Test_Database_Config">
        <db:generic-connection url="jdbc:h2:tcp://localhost/mem:DATABASE_NAME" driverClassName="org.h2.Driver" />
    </db:config>
    ```

6.  Define the `db.properties` file in your `src/test/resources` folder that will pick up your test
    database configuration:

    ```none
    db.config=Test_Database_Config
    ```

## Run the Test

After installing and configuring the DB server you can run the test:

```xml
<munit:test name="selectFlowTest" description="Test selectFlow"  >
    <munit:behavior>
        <!-- Passes a variable to value to run in the main flow. -->
        <set-variable variableName="jobid" value="DEV" />
    </munit:behavior>
    <munit:execution>
        <!-- Run the production code. -->
        <flow-ref name="db-server-docsFlow"/>
    </munit:execution>
    <munit:validation>
        <munit-tools:assert-equals actual="#[vars.job]" expected="Developer" />
    </munit:validation>
</munit:test>
```

This test validates that the query run in your production code is correct and that the payload
returned by the DB server is as expected.

## See Also

- [Database Util](https://docs.mulesoft.com/munit/2.3/db-util)

<!-- document id=0e9a72db9d681244845d4570c31e2de3b6a8290c337be345346b910466d3d7bd url=/mulesoft/current/en-us/munit/2.3/ftp-server-cookbook.md -->

---
product: MUnit
version: 2.3
---

# Configuring FTP Server Utility in an MUnit Test

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

Assume that you want to test the following Mule application:

```xml
<sftp:config name="SFTP_Config">
    <sftp:connection host="${ftp.host}" port="${ftp.port}" username="${ftp.user}" password="${ftp.password}"/>
</sftp:config>

<configuration-properties file="ftp.properties" />

<flow name="listFlow">
    <sftp:list config-ref="SFTP_Config" directoryPath="."/>
    <foreach>
        <logger level="INFO" message="#[attributes.fileName]"/>
    </foreach>
</flow>
```

The `ftp.properties` in `src/main/resources` has the following content:

```none
ftp.host=localhost
ftp.port=22
ftp.user=max
ftp.password=munittest
```

The username field cannot be empty. If you do not have a username-password pair, set the username to
`anonymous` and don’t set any password. By default, the `anonymous` attribute is set to `true`.

## Install the FTP Server

1.  From Anypoint Studio, go to the **Mule Palette** view and locate **Search in Exchange…​**.

2.  In the search bar look for **MUnit Utils FTP Server** and add the module to your project:

    ```xml
    <!-- Ftp Server Dependency -->
    <dependency>
        <groupId>com.mulesoft.munit.utils</groupId>
        <artifactId>munit-ftpserver-module</artifactId>
        <version>2.0.1</version>
        <classifier>mule-plugin</classifier>
        <scope>test</scope>
    </dependency>
    ```

    The MUnit FTP server artifact in your POM file must have the `test` scope.

## Define the FTP Server

1.  In your Studio canvas, go to the **Global Elements** tab and select your **MUnit FTP Server
    Config** element.

2.  Click **Edit** and complete the fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Attribute</th><th>Value</th></tr></thead><tbody><tr><td><div><div><p>Name</p></div></div></td><td><div><div><p><code>MUnit_FTP_Server_Config</code></p></div></div></td></tr><tr><td><div><div><p>Port</p></div></div></td><td><div><div><p><code>${ftp.port}</code></p></div></div></td></tr><tr><td><div><div><p>Username</p></div></div></td><td><div><div><p><code>${ftp.user}</code></p></div></div></td></tr><tr><td><div><div><p>Password</p></div></div></td><td><div><div><p><code>${ftp.password}</code></p></div></div></td></tr><tr><td><div><div><p>Secure</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td></tr><tr><td><div><div><p>homeDir</p></div></div></td><td><div><div><p><code>${app.home}</code></p></div></div></td></tr></tbody></table>

    ```xml
    <ftpserver:config name="MUnit_FTP_Server_Config">
        <ftpserver:connection port="${ftp.port}" username="${ftp.user}" password="${ftp.password}" secure="true" homeDir="${app.home}"/>
    </ftpserver:config>
    ```

## Run the Test

After configuring the FTP server you can run the test:

```xml
<munit:test name="listFlowTest" description="Test listFlow" >
    <munit:execution>
        <flow-ref name="listFlow"/>
    </munit:execution>
    <munit:validation>
        <munit-tools:assert-that expression="#[sizeOf(payload)]" is="#[MunitTools::greaterThan(0)]"/>
    </munit:validation>
</munit:test>
```

This FTP accepts any user, so there is no need to set up a user database or list.

## See Also

- [FTP Util](https://docs.mulesoft.com/munit/2.3/ftp-util)

<!-- document id=50965102f6cbf13cc5a72381b0884250212dcf216218036c13c7bb1834ecae86 url=/mulesoft/current/en-us/munit/3.6/db-server-cookbook.md -->

---
product: MUnit
version: 3.6
---

# Configuring the Database Server Utility in an MUnit Test

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

If you want to test the following Mule application:

```xml
<!-- Local Database Configuration -->
<db:config name="Database_Config">
    <db:my-sql-connection host="localhost" port="1234" />
</db:config>
<!-- Properties according to the environment -->
<configuration-properties file="db.properties" />

<flow name="selectFlow" >
    <!-- Perform a query based on a value passed by a variable -->
    <db:select config-ref="${db.config}">
        <db:sql >SELECT * FROM jobtitlelookup WHERE jobtitleid = :id</db:sql>
        <db:input-parameters ><![CDATA[#[id : vars.jobid]]]></db:input-parameters>
    </db:select>
    <!-- Set two conditions depending on the query result -->
    <choice>
        <!-- If there is one or more values resulting from the query set those values as the payload -->
        <when expression="#[sizeOf(payload) > 0]">
            <set-payload value="#[payload[0].jobtitle]"/>
        </when>
        <!-- If the query throws no results, inform it in the payload  -->
        <otherwise>
            <set-payload value="#['No job title for $(vars.jobid) was found']" />
        </otherwise>
    </choice>

    <!-- Finally, pass the payload content as a Flow variable  -->
    <set-variable value="#[payload]" variableName="job" />
</flow>
```

The file `db.properties` in `src/main/resources` has the following content:

```none
db.config=Database_Config
```

You must create a test that:

- Contains a database server with a `jobtitlelookup` table.

- Provides a valid database structure for the database connector to perform its query.

- Passes a value for the `jobid` variable that Database Connector uses.

## Install the MUnit DB Server Module

1.  Look for the **MUnit Utils Database Server** module.

2.  Add the module to your project:

    ```xml
    <!-- dbserver Dependency -->
    <dependency>
        <groupId>com.mulesoft.munit.utils</groupId>
        <artifactId>munit-dbserver-module</artifactId>
        <version>2.0.2</version>
        <classifier>mule-plugin</classifier>
        <scope>test</scope>
    </dependency>
    ```

    The MUnit DB server artifact in your POM file must have the `test` scope.

3.  Add the `h2` dependency to your POM file and list it as `sharedLibrary` in `mule-maven-plugin`:

    ```xml
    <!--Third party libs-->
    <dependency>
        <groupId>com.h2database</groupId>
        <artifactId>h2</artifactId>
        <version>1.3.166</version>
    </dependency>
    ```

    ```xml
    <plugin>
        <groupId>org.mule.tools.maven</groupId>
        <artifactId>mule-maven-plugin</artifactId>
        <version>${mule.maven.plugin.version}</version>
        <extensions>true</extensions>
        <configuration>
        <sharedLibraries>
                ...
                <sharedLibrary>
                    <groupId>com.h2database</groupId>
                    <artifactId>h2</artifactId>
                </sharedLibrary>
            </sharedLibraries>
        </configuration>
    </plugin>
    ```

The **h2** dependency enhances MUnit tests by allowing the simulation of database interactions using
an in-memory, lightweight, and fast database. This setup ensures tests are both isolated and
repeatable.

> [!NOTE] The **MUnit DB Server** module is located at
> [MuleSoft Nexus repository](https://repository.mulesoft.org/nexus/content/repositories/releases/com/mulesoft/munit/utils/munit-dbserver-module/).
> The **MUnit DB Server** module version 3 and later is compatible with Java 17. Previous versions
> of this module available at Anypoint Exchange are deprecated.

## Define the MUnit DB Server

Define the database server by creating the **global-configs.xml** file and defining the MUnit DB
Server Config element.

Define the MUnit DB Server Config element as follows:

1.  Go to the `src/test/resources` directory in your project.

2.  Create a file named `jobtitlelookup.csv` containing the following values:

    ```text
    JOBTITLE,EECSALARYORHOURLY,JOBTITLEID
    Developer,10,DEV
    ```

3.  Create the **global-configs.xml** file and define the **MUnit DB Server Config** element as
    follows:

    ```xml
    <dbserver:config name="MUnit_DB_Server_Config" >
        <dbserver:connection csv="jobtitlelookup.csv" database="DATABASE_NAME" connectionStringParameters="MODE=MySQL" />
    </dbserver:config>
    ```

4.  Define the DB configuration to connect to your DB server:

    ```xml
    <db:config name="Test_Database_Config">
        <db:generic-connection url="jdbc:h2:tcp://localhost/mem:DATABASE_NAME" driverClassName="org.h2.Driver" />
    </db:config>
    ```

5.  Define the `db.properties` file in your `src/test/resources` folder that picks up your test
    database configuration:

    ```none
    db.config=Test_Database_Config
    ```

## Run the Test

After installing and configuring the DB server you can run the test:

```xml
<munit:test name="selectFlowTest" description="Test selectFlow"  >
    <munit:behavior>
        <!-- Passes a variable to value to run in the main flow. -->
        <set-variable variableName="jobid" value="DEV" />
    </munit:behavior>
    <munit:execution>
        <!-- Run the production code. -->
        <flow-ref name="db-server-docsFlow"/>
    </munit:execution>
    <munit:validation>
        <munit-tools:assert-equals actual="#[vars.job]" expected="Developer" />
    </munit:validation>
</munit:test>
```

This test validates that the query run in your production code is correct and that the DB server
returns the payload as expected.

## See Also

- [Database Util](https://docs.mulesoft.com/munit/3.6/db-util)

- [Add Modules to Your Test in Anypoint Code Builder](https://docs.mulesoft.com/anypoint-code-builder/ref-acb-commands)

- [Add Modules to Your Test in Anypoint Studio](https://docs.mulesoft.com/studio/add-modules-in-studio-to)

<!-- document id=e1c9ff35cc59c7c4d7aa392a2ac4acc50f86f035d3fa53cd6f7700b84e82346c url=/mulesoft/current/en-us/munit/3.6/ftp-server-cookbook.md -->

---
product: MUnit
version: 3.6
---

# Configuring the FTP Server Utility in an MUnit Test

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

If you want to test the following Mule application:

```xml
<sftp:config name="SFTP_Config">
    <sftp:connection host="${ftp.host}" port="${ftp.port}" username="${ftp.user}" password="${ftp.password}"/>
</sftp:config>

<configuration-properties file="ftp.properties" />

<flow name="listFlow">
    <sftp:list config-ref="SFTP_Config" directoryPath="."/>
    <foreach>
        <logger level="INFO" message="#[attributes.fileName]"/>
    </foreach>
</flow>
```

The `ftp.properties` in `src/main/resources` has the following content:

```none
ftp.host=localhost
ftp.port=22
ftp.user=max
ftp.password=munittest
```

The username field can’t be empty. If you don’t have a username-password pair, set the username to
`anonymous` and don’t set any password. By default, the `anonymous` attribute is set to `true`.

## Install the FTP Server

To install the FTP server:

1.  Look for the **MUnit Utils FTP Server** module.

2.  Add the module to your project:

    ```xml
    <!-- Ftp Server Dependency -->
    <dependency>
        <groupId>com.mulesoft.munit.utils</groupId>
        <artifactId>munit-ftpserver-module</artifactId>
        <version>2.0.1</version>
        <classifier>mule-plugin</classifier>
        <scope>test</scope>
    </dependency>
    ```

    The MUnit FTP server artifact in your POM file must have the `test` scope.

> [!NOTE] The **MUnit FTP Server** module is located at
> [MuleSoft Nexus repository](https://repository.mulesoft.org/nexus/content/repositories/releases/com/mulesoft/munit/utils/munit-ftpserver-module/).
> The **MUnit FTP Server** module version 3 and later is compatible with Java 17. Previous versions
> of this module available at Anypoint Exchange are deprecated.

## Define the FTP Server

To define the FTP server, change the FTP server attributes as follows:

```xml
<ftpserver:config name="MUnit_FTP_Server_Config">
    <ftpserver:connection port="${ftp.port}" username="${ftp.user}" password="${ftp.password}" secure="true" homeDir="${app.home}"/>
----
</ftpserver:config>
----
```

## Run the Test

After configuring the FTP server, you can run the test:

```xml
<munit:test name="listFlowTest" description="Test listFlow" >
    <munit:execution>
        <flow-ref name="listFlow"/>
    </munit:execution>
    <munit:validation>
        <munit-tools:assert-that expression="#[sizeOf(payload)]" is="#[MunitTools::greaterThan(0)]"/>
    </munit:validation>
</munit:test>
```

This FTP accepts any user, so you must not set up a user database or list.

## See Also

- [FTP Util](https://docs.mulesoft.com/munit/3.6/ftp-util)

<!-- document id=6fe11a91e24af1918e6b816ef17cfcaa4434959630087a9a615f917ffb50e1f7 url=/mulesoft/current/en-us/munit/2.3/core-matchers-reference.md -->

---
product: MUnit
version: 2.3
---

# Core Matchers Reference

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

## nullValue()

Checks that the expression is null.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::nullValue()]"/>
```

## notNullValue()

Checks that the expression is not null.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::notNullValue()]"/>
```

## withMediaType(String)

Checks that the expression’s media type is the one specified.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::withMediaType('text/xml')]"/>
```

## withEncoding(String)

Checks that the expression encoding is the one specified.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::withEncoding('UTF-8')]"/>
```

## both(Matcher, Matcher)

Checks that both provided matchers are successful.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::both(MunitTools::notNullValue(),MunitTools::equalTo('example'))]"/>
```

## either(Matcher,Matcher)

Checks that at least one of the matchers is successful.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::either(MunitTools::nullValue(),MunitTools::equalTo(0))]"/>
```

## not(Object)

Checks if the provided matcher is not successful.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::not(0)]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::not(MunitTools::equalTo(0))]"/>
```

## anyOf(Array<Matcher>)

Checks if any of the matchers are successful.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::anyOf([MunitTools::notNullValue(),MunitTools::withMediaType('text/xml'),MunitTools::isEmptyString()])]"/>
```

## allOf(Array<Matcher>)

Checks if all of the matchers are successful.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::allOf([MunitTools::notNullValue(),MunitTools::withMediaType('text/xml'),MunitTools::isEmptyString()])]"/>
```

## See Also

- [MUnit Matchers](https://docs.mulesoft.com/munit/2.3/munit-matchers)

- [String Matchers Reference](https://docs.mulesoft.com/munit/2.3/string-matchers-reference)

- [Comparable Matchers Reference](https://docs.mulesoft.com/munit/2.3/comparable-matchers-reference)

- [Iterable and Map Matchers Reference](https://docs.mulesoft.com/munit/2.3/iterable-map-matchers-reference)

<!-- document id=7d192b6a0357a0413764b4d261b1520fba510a01f83b9b5352ea6c4a35b27299 url=/mulesoft/current/en-us/munit/3.6/core-matchers-reference.md -->

---
product: MUnit
version: 3.6
---

# Core Matchers Reference

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

## nullValue()

Checks that the expression is null.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::nullValue()]"/>
```

## notNullValue()

Checks that the expression is not null.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::notNullValue()]"/>
```

## withMediaType(String)

Checks that the expression’s media type is the one specified.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::withMediaType('text/xml')]"/>
```

## withEncoding(String)

Checks that the expression encoding is the one specified.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::withEncoding('UTF-8')]"/>
```

## both(Matcher, Matcher)

Checks that both provided matchers are successful.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::both(MunitTools::notNullValue(),MunitTools::equalTo('example'))]"/>
```

## either(Matcher,Matcher)

Checks that at least one of the matchers is successful.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::either(MunitTools::nullValue(),MunitTools::equalTo(0))]"/>
```

## not(Object)

Checks if the provided matcher is not successful.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::not(0)]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::not(MunitTools::equalTo(0))]"/>
```

## anyOf(Array<Matcher>)

Checks if any of the matchers are successful.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::anyOf([MunitTools::notNullValue(),MunitTools::withMediaType('text/xml'),MunitTools::isEmptyString()])]"/>
```

## allOf(Array<Matcher>)

Checks if all of the matchers are successful.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::allOf([MunitTools::notNullValue(),MunitTools::withMediaType('text/xml'),MunitTools::isEmptyString()])]"/>
```

## See Also

- [MUnit Matchers](https://docs.mulesoft.com/munit/3.6/munit-matchers)

- [String Matchers Reference](https://docs.mulesoft.com/munit/3.6/string-matchers-reference)

- [Comparable Matchers Reference](https://docs.mulesoft.com/munit/3.6/comparable-matchers-reference)

- [Iterable and Map Matchers Reference](https://docs.mulesoft.com/munit/3.6/iterable-map-matchers-reference)

<!-- document id=f5fbf901dfdc25a1d79487e10b88577329360d317cf20c72585c37fc37afd059 url=/mulesoft/current/en-us/munit/2.3/munit-coverage-report.md -->

---
product: MUnit
version: 2.3
---

# Coverage

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

The MUnit Coverage feature provides a measurement of how much of a Mule application has been
executed by a set of MUnit tests by counting the amount of event processors executed. This allows
you to obtain a quality standard for your application, and provides metrics for:

- Application overall coverage: An average of the items below.

- Resource coverage: Refers to each Mule configuration file under src/main/mule.

- Flow coverage: Refers to any of the following components: Flows, Sub-flows, and Batch jobs.

Coverage report runs only for EE edition runtimes. If your application has a `requiredProduct` of a
Mule CE runtime you will see the following message: **Coverage is a EE only feature and you’ve
selected to run over CE**. To run against an EE runtime see
[Specifying the Runtime Product](https://docs.mulesoft.com/munit/2.3/munit-maven-plugin#specify-runtime-product).

The following is a coverage report sample in JSON format.  
Use the code callouts below to understand each field in the report:

MUnit Coverage - sample JSON report

```json
{
  "coverage": 75.0, (1)
  "requiredApplicationCoverage": 40.0, (2)
  "requiredResourceCoverage": 30.0,    (2)
  "requiredFlowCoverage": 25.0,        (2)
  "flowCount": 3,             (3)
  "processorCount": 4,        (4)
  "coveredProcessorCount": 3, (5)
  "files": [ {
    "name": "file1.xml", (6)
    "flowCount": 1,      (7)
    "coverage": 100.0,   (8)
    "processorCount": 2, (9)
    "weight": 50.0,     (10)
    "flows": [ {
      "name": "file1Flow1", (11)
      "type": "FLOW",       (12)
      "coverage": 100.0,    (13)
      "messageProcessorCount": 2, (14)
      "coveredProcessorCount": 2, (15)
      "lines": [ { (16)
        "lineNumber": 11,
        "covered": true
      }, {
        "lineNumber": 12,
        "covered": true
      } ]
    } ]
  }, {
    "name": "file2.xml",
    "flowCount": 2,
    "coverage": 50.0,
    "processorCount": 2,
    "weight": 50.0,
    "flows": [ {
      "name": "file2Flow2",
      "type": "SCOPE",
      "coverage": 100.0,
      "messageProcessorCount": 1,
      "coveredProcessorCount": 1,
      "lines": [ {
        "lineNumber": 10,
        "covered": true
      } ]
    }, {
      "name": "file2Flow1",
      "type": "SCOPE",
      "coverage": 0.0,
      "messageProcessorCount": 1,
      "coveredProcessorCount": 0,
      "lines": [  {
        "lineNumber": 7,
        "covered": false
      } ]
    } ]
  } ]
}
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Coverage percentage of the whole application.</td></tr><tr><td><i data-value="2"></i><b>2</b></td><td>Required coverages for application, resources, and flows. If not configured, they default to -1.</td></tr><tr><td><i data-value="3"></i><b>3</b></td><td>Amount of flows in the application.</td></tr><tr><td><i data-value="4"></i><b>4</b></td><td>Amount of event processors in the application.</td></tr><tr><td><i data-value="5"></i><b>5</b></td><td>Amount of covered event processors.</td></tr><tr><td><i data-value="6"></i><b>6</b></td><td>Name of that file.</td></tr><tr><td><i data-value="7"></i><b>7</b></td><td>Amount of flows in that file.</td></tr><tr><td><i data-value="8"></i><b>8</b></td><td>Coverage percentage of that file.</td></tr><tr><td><i data-value="9"></i><b>9</b></td><td>Amount of event processors in that file.</td></tr><tr><td><i data-value="10"></i><b>10</b></td><td>Contribution of that file to the coverage percentage of the whole application.</td></tr><tr><td><i data-value="11"></i><b>11</b></td><td>Name of the flow.</td></tr><tr><td><i data-value="12"></i><b>12</b></td><td>Type of the top level element.<br>Other type of top level element in coverage is error-handler.</td></tr><tr><td><i data-value="13"></i><b>13</b></td><td>Coverage percentage of that flow.</td></tr><tr><td><i data-value="14"></i><b>14</b></td><td>Amount of event processors in that flow.</td></tr><tr><td><i data-value="15"></i><b>15</b></td><td>Amount of event processors covered in that flow.</td></tr><tr><td><i data-value="16"></i><b>16</b></td><td>XML line numbers containing event processors in that file, and whether they were covered or not.</td></tr></tbody></table>

## See Also

- [Coverage in Maven](https://docs.mulesoft.com/munit/2.3/coverage-maven-concept)

<!-- document id=89e0b543ef57021f23727e2c96fe402c3a9b10fc37d9e314a1a3c7640dd75c42 url=/mulesoft/current/en-us/munit/3.6/munit-coverage-report.md -->

---
product: MUnit
version: 3.6
---

# Coverage

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The MUnit Coverage feature provides a measurement of how much of a Mule application has been
executed by a set of MUnit tests by counting the amount of event processors executed. This allows
you to obtain a quality standard for your application, and provides metrics for:

- Application overall coverage: An average of the items below.

- Resource coverage: Refers to each Mule configuration file under src/main/mule.

- Flow coverage: Refers to any of the following components: Flows, Sub-flows, and Batch jobs.

Coverage report runs only for EE edition runtimes. If your application has a `requiredProduct` of a
Mule CE runtime you will see the following message: **Coverage is a EE only feature and you’ve
selected to run over CE**. To run against an EE runtime see
[Specifying the Runtime Product](https://docs.mulesoft.com/munit/3.6/munit-maven-plugin#specify-runtime-product).

The following is a coverage report sample in JSON format.  
Use the code callouts below to understand each field in the report:

MUnit Coverage - sample JSON report

```json
{
  "coverage": 75.0, (1)
  "requiredApplicationCoverage": 40.0, (2)
  "requiredResourceCoverage": 30.0,    (2)
  "requiredFlowCoverage": 25.0,        (2)
  "flowCount": 3,             (3)
  "processorCount": 4,        (4)
  "coveredProcessorCount": 3, (5)
  "files": [ {
    "name": "file1.xml", (6)
    "flowCount": 1,      (7)
    "coverage": 100.0,   (8)
    "processorCount": 2, (9)
    "weight": 50.0,     (10)
    "flows": [ {
      "name": "file1Flow1", (11)
      "type": "FLOW",       (12)
      "coverage": 100.0,    (13)
      "messageProcessorCount": 2, (14)
      "coveredProcessorCount": 2, (15)
      "lines": [ { (16)
        "lineNumber": 11,
        "covered": true
      }, {
        "lineNumber": 12,
        "covered": true
      } ]
    } ]
  }, {
    "name": "file2.xml",
    "flowCount": 2,
    "coverage": 50.0,
    "processorCount": 2,
    "weight": 50.0,
    "flows": [ {
      "name": "file2Flow2",
      "type": "SCOPE",
      "coverage": 100.0,
      "messageProcessorCount": 1,
      "coveredProcessorCount": 1,
      "lines": [ {
        "lineNumber": 10,
        "covered": true
      } ]
    }, {
      "name": "file2Flow1",
      "type": "SCOPE",
      "coverage": 0.0,
      "messageProcessorCount": 1,
      "coveredProcessorCount": 0,
      "lines": [  {
        "lineNumber": 7,
        "covered": false
      } ]
    } ]
  } ]
}
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Coverage percentage of the whole application.</td></tr><tr><td><i data-value="2"></i><b>2</b></td><td>Required coverages for application, resources, and flows. If not configured, they default to -1.</td></tr><tr><td><i data-value="3"></i><b>3</b></td><td>Amount of flows in the application.</td></tr><tr><td><i data-value="4"></i><b>4</b></td><td>Amount of event processors in the application.</td></tr><tr><td><i data-value="5"></i><b>5</b></td><td>Amount of covered event processors.</td></tr><tr><td><i data-value="6"></i><b>6</b></td><td>Name of that file.</td></tr><tr><td><i data-value="7"></i><b>7</b></td><td>Amount of flows in that file.</td></tr><tr><td><i data-value="8"></i><b>8</b></td><td>Coverage percentage of that file.</td></tr><tr><td><i data-value="9"></i><b>9</b></td><td>Amount of event processors in that file.</td></tr><tr><td><i data-value="10"></i><b>10</b></td><td>Contribution of that file to the coverage percentage of the whole application.</td></tr><tr><td><i data-value="11"></i><b>11</b></td><td>Name of the flow.</td></tr><tr><td><i data-value="12"></i><b>12</b></td><td>Type of the top level element.<br>Other type of top level element in coverage is error-handler.</td></tr><tr><td><i data-value="13"></i><b>13</b></td><td>Coverage percentage of that flow.</td></tr><tr><td><i data-value="14"></i><b>14</b></td><td>Amount of event processors in that flow.</td></tr><tr><td><i data-value="15"></i><b>15</b></td><td>Amount of event processors covered in that flow.</td></tr><tr><td><i data-value="16"></i><b>16</b></td><td>XML line numbers containing event processors in that file, and whether they were covered or not.</td></tr></tbody></table>

## See Also

- [Coverage in Maven](https://docs.mulesoft.com/munit/3.6/coverage-maven-concept)

<!-- document id=7eb1cb5fc7f23bafb5c6172730e269d41d84f92953b96580780cb2f68192bd8f url=/mulesoft/current/en-us/munit/2.3/db-util.md -->

---
product: MUnit
version: 2.3
---

# Database

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

To test a piece of code that connects with a database server, you must install a database server in
your local environment to run the tests. You could also have a dedicated external database server
for testing, but your Maven project would not be portable — a third party would need to install the
testing database server to compile your project.

To make it easier for you to test database connections, MUnit allows you to implement a database
server in your local environment.

## Install the MUnit DB Server Module

1.  From Anypoint Studio, go to the **Mule Palette** and **Search in Exchange…​**.

2.  In the search bar look for **MUnit Utils Database Server**, and add the module to your project.

    ```xml
    <!-- dbserver Dependency -->
    <dependency>
        <groupId>com.mulesoft.munit.utils</groupId>
        <artifactId>munit-dbserver-module</artifactId>
        <version>2.0.2</version>
        <classifier>mule-plugin</classifier>
        <scope>test</scope>
    </dependency>
    ```

    The MUnit DB server artifact in your `pom` file must have the `test` scope.

3.  The `h2` dependency used for the database is a shared library.  
    You must add the dependency to your `pom.xml` file and list it as a `sharedLibrary` in the
    `mule-maven-plugin`.

    ```xml
    <!--Third party libs-->
    <dependency>
        <groupId>com.h2database</groupId>
        <artifactId>h2</artifactId>
        <version>1.3.166</version>
    </dependency>
    ```

    ```xml
    <plugin>
        <groupId>org.mule.tools.maven</groupId>
        <artifactId>mule-maven-plugin</artifactId>
        <version>${mule.maven.plugin.version}</version>
        <extensions>true</extensions>
        <configuration>
        <sharedLibraries>
                ...
                <sharedLibrary>
                    <groupId>com.h2database</groupId>
                    <artifactId>h2</artifactId>
                </sharedLibrary>
            </sharedLibraries>
        </configuration>
    </plugin>
    ```

## Attributes Reference

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>name</code></p></td><td><p>Defines the configuration name of this DB server. This value must be unique.</p></td></tr><tr><td><p><code>database</code></p></td><td><p>Defines the name of the in-memory DB.</p></td></tr><tr><td><p><code>sqlFile</code></p></td><td><p>Specifies the path of the SQL file that defines the DB structure/contents. This parameter is used to create the DB at startup. See the <a href="#db-structure-sql">Defining the DB Structure from an SQL File</a> section for more information.</p></td></tr><tr><td><p><code>csv</code></p></td><td><p>Specifies the path of the-comma separated file used to define the DB structure/contents. This parameter is used to create the DB at startup. See <a href="#db-structure-csv">Defining the DB Structure from a CSV File</a> section for more information.</p></td></tr><tr><td><p><code>connectionStringParameters</code></p></td><td><p>Defines the connection string for your database. You can concatenate the parameters with a semicolon.</p></td></tr></tbody></table>

## Define the DB Structure

There are two different ways to define the structure and content of your database:

- SQL

- CSV

The MUnit DB server is based on H2. Complex structures, index and join commands may not work
properly.

### Defining the DB Structure from an SQL File

To define the DB structure and content from an SQL file, you must provide a valid set of ANSI SQL
DDL (Data Definition Language) instructions.

```xml
<dbserver:config name="MUnit_DB_Server_Config" >
    <dbserver:connection sqlFile="FILE_NAME.sql" database="DATABASE_NAME" connectionStringParameters="MODE=MySQL" />
</dbserver:config>
```

### Define the DB Structure From a CSV File

To define your DB structure based on a CSV file:

- The name of the table is the name of the file (in the example below, `customers`).

- The name of the columns are the headers of your CSV file.

```xml
<dbserver:config name="MUnit_DB_Server_Config" >
    <dbserver:connection csv="FILE_NAME.csv" database="DATABASE_NAME" connectionStringParameters="MODE=MySQL" />
</dbserver:config>
```

You can also split your DB structure among several CSV files. To do this, include the file names in
a list, with the names separated by semicolons:

```xml
<dbserver:config name="MUnit_DB_Server_Config" >
    <dbserver:connection csv="FILE_NAME.csv;FILE_NAME_1.csv" database="DATABASE_NAME" connectionStringParameters="MODE=MySQL" />
</dbserver:config>
```

This creates two tables: `FILE_NAME` and `FILE_NAME_1`.

## MUnit DB Server Processors

The DB server utility has two processors to interact with your DB server:

### Validate-That

The MUnit DB Server allows you to validate that the results of a query are as expected.

To do this, you use the `validate-that` operation. Set the `results` property to CSV with rows
separated by a newline character (`\n`), as shown below.

```xml
<dbserver:validate-that config-ref="DB_Server"
query="SELECT * FROM jobtitlelookup WHERE JOBTITLE='Developer';" returns="&quot;JOBTITLE&quot;,&quot;EECSALARYORHOURLY&quot;,&quot;JOBTITLEID&quot;\n&quot;Developer&quot;,&quot;10&quot;,&quot;DEV&quot;" />
```

### Execute

MUnit DB Server enables you to execute instructions to the in-memory databases so that you can add
or remove registries before a test and verify that your data was stored correctly.

Use a DB Server connector with the `execute` operation to insert the new values to the table
(`Culinary Team Member,10,HIR`), then use another DB Server connector with an `execute query`
operation to retrieve all values from the table (including the newly added ones) and check the
payload using a logger component to store the payload:

```xml
<!-- Execute a SQL instruction using the execute operation -->
<dbserver:execute config-ref="MUnit_DB_Server_Config" sql="INSERT INTO jobtitlelookup VALUES ('Culinary Team Member','10','HIR');"/>

<!-- Check the update using execute-query operation -->
<dbserver:execute-query config-ref="MUnit_DB_Server_Config" sql="SELECT * FROM jobtitlelookup"/>

<!-- log the resulting payload -->
<logger level="INFO" message="#[payload]"/>
```

The logger in your console reads:

```text
org.mule.runtime.core.internal.processor.LoggerMessageProcessor: [{JOBTITLEID=DEV, EECSALARYORHOURLY=10, JOBTITLE=Developer}, {JOBTITLEID=HIR, EECSALARYORHOURLY=10, JOBTITLE=Culinary Team Member}]
```

## See Also

- [Configuring DB Server Utility in an MUnit Test](https://docs.mulesoft.com/munit/2.3/db-server-cookbook)

<!-- document id=d1e6ae37d954e57d930968e2721eb823f3b0a0b3a3f29ea688d3eff5a366d728 url=/mulesoft/current/en-us/munit/2.3/dataweave-assertions-library.md -->

---
product: MUnit
version: 2.3
---

# DataWeave Assertions Library

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

## dw::test::Asserts

This module contains the set of core Matchers to use in your tests

Example

```dataweave
%dw 2.0
import dw::tests::Asserts
---
payload must beObject()
```

Validates if a payload is of type Object

## Functions

### anyOf

#### anyOf(Array<Matcher<Any>>): Matcher<Any>

Validates that the value satisfies at least one of the given matchers

```dataweave
%dw 2.0
import dw::tests::Asserts
---
"A Text" must anyOf([beObject(), beString()])
```

### beArray

#### beArray(): Matcher

Validates that a given value is of type Array

```dataweave
%dw 2.0
import dw::tests::Asserts
---
[1, 4, 7] must beArray()
```

### beBlank

#### beBlank(): Matcher<String | Null>

Validates that the String value is blank

```dataweave
%dw 2.0
import dw::tests::Asserts
---
"  " must beBlank()
```

### beBoolean

#### beBoolean(): Matcher

Validates that a given value is of type Boolean

```dataweave
%dw 2.0
import dw::tests::Asserts
---
true must beBoolean()
```

### beEmpty

#### beEmpty(): Matcher<String | Object | Array | Null>

Validates that the value (String, Object or Array) is empty

```dataweave
%dw 2.0
import dw::tests::Asserts
---
[] must beEmpty()
```

### beGreaterThan

#### beGreaterThan(Comparable, Boolean): Matcher<Comparable>

Validates that the asserted Comparable value is greater than the given one

Can be equal to when using the _inclusive_ argument

```dataweave
%dw 2.0
import dw::tests::Asserts
---
3 must beGreaterThan(2)
```

### beLowerThan

#### beLowerThan(Comparable, Boolean): Matcher<Comparable>

Validates that the asserted Comparable value is lower than the given one

Can be equal to when using the _inclusive_ argument

```dataweave
%dw 2.0
import dw::tests::Asserts
---
1 must beLowerThan(2)
```

### beNull

#### beNull(): Matcher

Validates that a given value is of type Null

```dataweave
%dw 2.0
import dw::tests::Asserts
---
null must beNull()
```

### beNumber

#### beNumber(): Matcher

Validates that a given value is of type Number

```dataweave
%dw 2.0
import dw::tests::Asserts
---
123 must beNumber()
```

### beObject

#### beObject(): Matcher

Validates that a given value is of type Object

```dataweave
%dw 2.0
import dw::tests::Asserts
---
{ name : "Lionel", lastName: "Messi"} must beObject()
```

### beOneOf

#### beOneOf(Array<Any>): Matcher

Validates that the value is contained in the given Array

```dataweave
%dw 2.0
import dw::tests::Asserts
---
1 must beOneOf([1, "A Text", true])
```

### beString

#### beString(): Matcher

Validates that a given value is of type String

```dataweave
%dw 2.0
import dw::tests::Asserts
---
"A Text" must beString()
```

### contain

#### contain(String): Matcher<String>

Validates that the asserted String contains the given String

```dataweave
%dw 2.0
import dw::tests::Asserts
---
"A Text" must contain("ex")
```

#### contain(Any): Matcher<Array<Any>>

Validates that the asserted Array contains the given value

```dataweave
%dw 2.0
import dw::tests::Asserts
---
[1, "A Text", true] must contain(1)
```

### eachItem

#### eachItem(Matcher<Any>): Matcher<Array<Any>>

Validates that each item of the array satisfies the given matcher

```dataweave
%dw 2.0
import dw::tests::Asserts
---
[1,2,3] must eachItem(beNumber())
```

### endWith

#### endWith(String): Matcher<String>

Validates that the asserted String ends with the given String

```dataweave
%dw 2.0
import dw::tests::Asserts
---
"A Text" must endWith("xt")
```

### equalTo

#### equalTo(Any, { unordered?: Boolean }): Matcher<Any>

Validates that a value is equal to another one

```dataweave
%dw 2.0
import dw::tests::Asserts
---
(1 + 2) must equalTo(3)
```

### equalToResource

#### equalToResource(String, String, Object): Matcher<Any>

Validates that the given value is equal to the content of a resource file

The resource file must belong to the classpath

```dataweave
%dw 2.0
import dw::tests::Asserts
---
{ name: "Lionel", lastName: "Messi" } must equalToResource("user.json", "application/json")
```

### haveItem

#### haveItem(Matcher<Any>): Matcher<Array<Any>>

Validates that at least one item of the array satisfies the given matcher

```dataweave
%dw 2.0
import dw::tests::Asserts
---
[1, true, "a text"] must haveItem(beNumber())
```

### haveKey

#### haveKey(String): Matcher<Object>

Validates that the Object has the given key

```dataweave
%dw 2.0
import dw::tests::Asserts
---
{ name: "Lionel", lastName: "Messi" } must haveKey("name")
```

### haveSize

#### haveSize(Number): Matcher<Array | String | Object>

Validates that the array has the given size

```dataweave
%dw 2.0
import dw::tests::Asserts
---
[1, 4, 7] must haveSize(3)
```

### haveValue

#### haveValue(Any): Matcher<Object>

Validates that the Object has the given value

```dataweave
%dw 2.0
import dw::tests::Asserts
---
{ name: "Lionel", lastName: "Messi" } must haveValue("Messi")
```

### must

#### must(T, Array<(value: T) → Matcher<T> | MatcherResult | Boolean>): MatcherResult

This function allows to assert a value with with a list of Matcher of Expressions

Example

```dataweave
%dw 2.0
import dw::tests::Asserts
---
payload must [
    beObject(),
    $.foo is Null
]
```

#### must(T, (value: T) → Matcher<T> | Boolean): MatcherResult

This function allows to assert a value with a Matcher of Expressions

Example

```dataweave
%dw 2.0
import dw::tests::Asserts
---
payload must beObject()
```

### notBe

#### notBe(Matcher<T>): Matcher<T>

Validates that the value doesn’t satisfy the given matcher

```dataweave
%dw 2.0
import dw::tests::Asserts
---
1 must notBe(equalTo(2))
```

### notBeNull

#### notBeNull(): Matcher

Validates that a given value isn’t of type Null

```dataweave
%dw 2.0
import dw::tests::Asserts
---
"A Text" must notBeNull()
```

### startWith

#### startWith(String): Matcher<String>

Validates that the asserted String starts with the given String

```dataweave
%dw 2.0
import dw::tests::Asserts
---
"A Text" must startWith("A")
```

## Variables

### MATCHED

Constant that represents a successful match

## Types

### Matcher

Data Type that represents a Matcher to perform assertions

Example

```dataweave
%dw 2.0
import dw::tests::Asserts

fun beEqualToOne(): Matcher<Any> =
    (actual) -> do {
        {
            matches: actual == 1,
            description: { expected: "To be 1", actual: write(actual) as String }
        }
    }
```

Definition

```dataweave
(value: T) -> MatcherResult
```

### MatcherResult

Data Type that represents the result of an Assertion

Example

```dataweave
{
  "matches": false,
  description : { expected : "Number type", actual: "A Text" }
}
```

Definition

```dataweave
{ matches: Boolean, description: { expected: String, actual: String }, reasons?: Array<String> }
```

<!-- document id=2edddaa129faf1c1f821daa3460fc5e0595bccf46b535dddfc63a56e505598a0 url=/mulesoft/current/en-us/munit/3.6/dataweave-assertions-library.md -->

---
product: MUnit
version: 3.6
---

# DataWeave Assertions Library

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

## dw::test::Asserts

This module contains the set of core Matchers to use in your tests

Example

```dataweave
%dw 2.0
import dw::tests::Asserts
---
payload must beObject()
```

Validates if a payload is of type Object

## Functions

### anyOf

#### anyOf(Array<Matcher<Any>>): Matcher<Any>

Validates that the value satisfies at least one of the given matchers

```dataweave
%dw 2.0
import dw::tests::Asserts
---
"A Text" must anyOf([beObject(), beString()])
```

### beArray

#### beArray(): Matcher

Validates that a given value is of type Array

```dataweave
%dw 2.0
import dw::tests::Asserts
---
[1, 4, 7] must beArray()
```

### beBlank

#### beBlank(): Matcher<String | Null>

Validates that the String value is blank

```dataweave
%dw 2.0
import dw::tests::Asserts
---
"  " must beBlank()
```

### beBoolean

#### beBoolean(): Matcher

Validates that a given value is of type Boolean

```dataweave
%dw 2.0
import dw::tests::Asserts
---
true must beBoolean()
```

### beEmpty

#### beEmpty(): Matcher<String | Object | Array | Null>

Validates that the value (String, Object or Array) is empty

```dataweave
%dw 2.0
import dw::tests::Asserts
---
[] must beEmpty()
```

### beGreaterThan

#### beGreaterThan(Comparable, Boolean): Matcher<Comparable>

Validates that the asserted Comparable value is greater than the given one

Can be equal to when using the _inclusive_ argument

```dataweave
%dw 2.0
import dw::tests::Asserts
---
3 must beGreaterThan(2)
```

### beLowerThan

#### beLowerThan(Comparable, Boolean): Matcher<Comparable>

Validates that the asserted Comparable value is lower than the given one

Can be equal to when using the _inclusive_ argument

```dataweave
%dw 2.0
import dw::tests::Asserts
---
1 must beLowerThan(2)
```

### beNull

#### beNull(): Matcher

Validates that a given value is of type Null

```dataweave
%dw 2.0
import dw::tests::Asserts
---
null must beNull()
```

### beNumber

#### beNumber(): Matcher

Validates that a given value is of type Number

```dataweave
%dw 2.0
import dw::tests::Asserts
---
123 must beNumber()
```

### beObject

#### beObject(): Matcher

Validates that a given value is of type Object

```dataweave
%dw 2.0
import dw::tests::Asserts
---
{ name : "Lionel", lastName: "Messi"} must beObject()
```

### beOneOf

#### beOneOf(Array<Any>): Matcher

Validates that the value is contained in the given Array

```dataweave
%dw 2.0
import dw::tests::Asserts
---
1 must beOneOf([1, "A Text", true])
```

### beString

#### beString(): Matcher

Validates that a given value is of type String

```dataweave
%dw 2.0
import dw::tests::Asserts
---
"A Text" must beString()
```

### contain

#### contain(String): Matcher<String>

Validates that the asserted String contains the given String

```dataweave
%dw 2.0
import dw::tests::Asserts
---
"A Text" must contain("ex")
```

#### contain(Any): Matcher<Array<Any>>

Validates that the asserted Array contains the given value

```dataweave
%dw 2.0
import dw::tests::Asserts
---
[1, "A Text", true] must contain(1)
```

### eachItem

#### eachItem(Matcher<Any>): Matcher<Array<Any>>

Validates that each item of the array satisfies the given matcher

```dataweave
%dw 2.0
import dw::tests::Asserts
---
[1,2,3] must eachItem(beNumber())
```

### endWith

#### endWith(String): Matcher<String>

Validates that the asserted String ends with the given String

```dataweave
%dw 2.0
import dw::tests::Asserts
---
"A Text" must endWith("xt")
```

### equalTo

#### equalTo(Any, { unordered?: Boolean }): Matcher<Any>

Validates that a value is equal to another one

```dataweave
%dw 2.0
import dw::tests::Asserts
---
(1 + 2) must equalTo(3)
```

### equalToResource

#### equalToResource(String, String, Object): Matcher<Any>

Validates that the given value is equal to the content of a resource file

The resource file must belong to the classpath

```dataweave
%dw 2.0
import dw::tests::Asserts
---
{ name: "Lionel", lastName: "Messi" } must equalToResource("user.json", "application/json")
```

### haveItem

#### haveItem(Matcher<Any>): Matcher<Array<Any>>

Validates that at least one item of the array satisfies the given matcher

```dataweave
%dw 2.0
import dw::tests::Asserts
---
[1, true, "a text"] must haveItem(beNumber())
```

### haveKey

#### haveKey(String): Matcher<Object>

Validates that the Object has the given key

```dataweave
%dw 2.0
import dw::tests::Asserts
---
{ name: "Lionel", lastName: "Messi" } must haveKey("name")
```

### haveSize

#### haveSize(Number): Matcher<Array | String | Object>

Validates that the array has the given size

```dataweave
%dw 2.0
import dw::tests::Asserts
---
[1, 4, 7] must haveSize(3)
```

### haveValue

#### haveValue(Any): Matcher<Object>

Validates that the Object has the given value

```dataweave
%dw 2.0
import dw::tests::Asserts
---
{ name: "Lionel", lastName: "Messi" } must haveValue("Messi")
```

### must

#### must(T, Array<(value: T) → Matcher<T> | MatcherResult | Boolean>): MatcherResult

This function allows to assert a value with a list of Matcher of Expressions

Example

```dataweave
%dw 2.0
import dw::tests::Asserts
---
payload must [
    beObject(),
    $.foo is Null
]
```

#### must(T, (value: T) → Matcher<T> | Boolean): MatcherResult

This function allows to assert a value with a Matcher of Expressions

Example

```dataweave
%dw 2.0
import dw::tests::Asserts
---
payload must beObject()
```

### notBe

#### notBe(Matcher<T>): Matcher<T>

Validates that the value doesn’t satisfy the given matcher

```dataweave
%dw 2.0
import dw::tests::Asserts
---
1 must notBe(equalTo(2))
```

### notBeNull

#### notBeNull(): Matcher

Validates that a given value isn’t of type Null

```dataweave
%dw 2.0
import dw::tests::Asserts
---
"A Text" must notBeNull()
```

### startWith

#### startWith(String): Matcher<String>

Validates that the asserted String starts with the given String

```dataweave
%dw 2.0
import dw::tests::Asserts
---
"A Text" must startWith("A")
```

## Variables

### MATCHED

Constant that represents a successful match

## Types

### Matcher

Data Type that represents a Matcher to perform assertions

Example

```dataweave
%dw 2.0
import dw::tests::Asserts

fun beEqualToOne(): Matcher<Any> =
    (actual) -> do {
        {
            matches: actual == 1,
            description: { expected: "To be 1", actual: write(actual) as String }
        }
    }
```

Definition

```dataweave
(value: T) -> MatcherResult
```

### MatcherResult

Data Type that represents the result of an Assertion

Example

```dataweave
{
  "matches": false,
  description : { expected : "Number type", actual: "A Text" }
}
```

Definition

```dataweave
{ matches: Boolean, description: { expected: String, actual: String }, reasons?: Array<String> }
```

<!-- document id=c2bcf68052b6721855d5789ed47e9837b2c3df8d4594d55a320c6cecba04acf4 url=/mulesoft/current/en-us/munit/2.3/dynamic-directories.md -->

---
product: MUnit
version: 2.3
---

# Dynamic Directories

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

When managing files and folders during a test, MUnit provides the `munit.temporary.directory`
property to reference a temporary directory. You can create files and folders inside this directory
to use in your tests.

The temporary directory is deleted at the end of each test.

For example, using the file connector, you could configure the working directory as follows:

```xml
<file:config name="tmpDir">
    <file:connection workingDir="${munit.temporary.directory}"/>
</file:config>
```

And then use it to create files/folders inside it:

```xml
<file:create-directory config-ref="tmpDir" directoryPath="example"/>
```

## See Also

- [Dynamic Ports](https://docs.mulesoft.com/munit/2.3/dynamic-ports)

<!-- document id=b9c24008ac01e7761f8464a2dad261062b379c821a53d61a1e5072c806a5f8b6 url=/mulesoft/current/en-us/munit/3.6/dynamic-directories.md -->

---
product: MUnit
version: 3.6
---

# Dynamic Directories

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

When managing files and folders during a test, MUnit provides the `munit.temporary.directory`
property to reference a temporary directory. You can create files and folders inside this directory
to use in your tests.

The temporary directory is deleted at the end of each test.

For example, using the file connector, you could configure the working directory as follows:

```xml
<file:config name="tmpDir">
    <file:connection workingDir="${munit.temporary.directory}"/>
</file:config>
```

And then use it to create files/folders inside it:

```xml
<file:create-directory config-ref="tmpDir" directoryPath="example"/>
```

## See Also

- [Dynamic Ports](https://docs.mulesoft.com/munit/3.6/dynamic-ports)

<!-- document id=e00290b7677dbf50a41286712630fd6ef6a98262226a19e39e177abd8cdc4e5d url=/mulesoft/current/en-us/munit/2.3/dynamic-ports.md -->

---
product: MUnit
version: 2.3
---

# Dynamic Ports

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

The Dynamic Ports global element allows you to bind a free port to a property. It searches for a
free port available and can be narrowed to a specific range.

For example, a dynamic port would look something like this:

```xml
<munit:dynamic-port propertyName="a.dynamic.port"/>
```

And it can be used in the http configuration:

```xml
<http:request-config name="httpRequestConfig">
    <http:request-connection host="localhost" port="${a.dynamic.port}"/>
</http:request-config>
```

Additionally you can set min and max values from where to get the port:

```xml
<munit:dynamic-port propertyName="a.dynamic.port" min="6000" max="7000"/>
```

## See Also

- [Dynamic Directories](https://docs.mulesoft.com/munit/2.3/dynamic-directories)

- [Storage Event Processors](https://docs.mulesoft.com/munit/2.3/storage-event-processors)

<!-- document id=b7d14592d159cc68c39ed7331783216d9c83d6e8c154e3e8d1534a915be6150f url=/mulesoft/current/en-us/munit/3.6/dynamic-ports.md -->

---
product: MUnit
version: 3.6
---

# Dynamic Ports

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The Dynamic Ports global element allows you to bind a free port to a property. It searches for a
free port available and can be narrowed to a specific range.

For example, a dynamic port would look something like this:

```xml
<munit:dynamic-port propertyName="a.dynamic.port"/>
```

And it can be used in the http configuration:

```xml
<http:request-config name="httpRequestConfig">
    <http:request-connection host="localhost" port="${a.dynamic.port}"/>
</http:request-config>
```

Additionally you can set min and max values from where to get the port:

```xml
<munit:dynamic-port propertyName="a.dynamic.port" min="6000" max="7000"/>
```

## See Also

- [Dynamic Directories](https://docs.mulesoft.com/munit/3.6/dynamic-directories)

- [Storage Event Processors](https://docs.mulesoft.com/munit/3.6/storage-event-processors)

<!-- document id=a675f5bdd253bda5d8ae18ec171e0258e1cb2d9be54debf0f68fe71453611108 url=/mulesoft/current/en-us/munit/2.3/enable-flow-sources-concept.md -->

---
product: MUnit
version: 2.3
keywords: munit, test, flow sources
---

# Enable Flow Sources

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

The Enable Flow Sources element within the MUnit test tells MUnit which flow sources to load and
execute for the test.

By default, MUnit does not start any of the event sources (flow sources such as triggers, and
listeners). You must configure which flow sources must start for your tests.

Assume that your application has a flow with an HTTP listener that returns a specific payload:

```xml
<http:listener-config name="HTTP_Listener_config">
    <http:listener-connection host="localhost" port="1234"/>
</http:listener-config>

<flow name="http-example-flow">
    <http:listener path="/" config-ref="HTTP_Listener_config"/>
    <set-payload value="#['Hello World!']" mimeType="text/plain"/>
</flow>
```

For MUnit to be able to invoke that listener you must enable the `http-example-flow` in your
`enable-flow-source` property within your MUnit test:

```xml
<http:request-config name="HTTP_Request_config">
    <http:request-connection host="localhost" port="1234"/>
</http:request-config>

<munit:test name="http-example-test">
    <munit:enable-flow-sources>
        <munit:enable-flow-source value="http-example-flow"/>
    </munit:enable-flow-sources>

    <munit:execution>
        <http:request method="GET" path="/" config-ref="HTTP_Request_config"/>
    </munit:execution>

    <munit:validation>
        <munit-tools:assert-that expression="#[payload]"
                                 is="#[MunitTools::equalTo('Hello World!')]"/>
    </munit:validation>
</munit:test>
```

If the `http-example-flow` value is not listed as an enabled flow source, your MUnit test fails
because it cannot initialize the HTTP listener configuration.

MUnit starts flow sources at the beginning of the test, and stops them at the end of the test. Flow
sources are not executed during the before-suite/before-test, nor during the
after-test/after-suite.  
See [Before/After scopes](https://docs.mulesoft.com/munit/2.3/before-after-scopes-reference) for more information.

## Enable Flow Sources from Anypoint Studio

You can define flow sources using the **Mule Properties** view of your MUnit test in Studio:

![Flow sources defined using the Mule Properties view in Studio.](/mulesoft/current/en-us/munit/2.3/_images/enable-flow-sources-concept.png)

1.  Click **Add**.

2.  Select the name of the flow you want to enable from the **Name of the flow** drop-down menu.

<!-- document id=c20bc32d08b4605b402560b378f301340c32459ca7650997dc962a53160236c8 url=/mulesoft/current/en-us/munit/3.6/enable-flow-sources-concept.md -->

---
product: MUnit
version: 3.6
keywords: munit, test, flow sources
---

# Enable Flow Sources

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The `Enable Flow Sources` element within the MUnit test instructs MUnit which flow sources to load
and execute for the test.

By default, MUnit doesn’t start any of the event sources (flow sources such as triggers and
listeners). You must configure which flow sources must start for your tests.

Assume that your application has a flow with an HTTP listener that returns a specific payload:

```xml
<http:listener-config name="HTTP_Listener_config">
    <http:listener-connection host="localhost" port="1234"/>
</http:listener-config>

<flow name="http-example-flow">
    <http:listener path="/" config-ref="HTTP_Listener_config"/>
    <set-payload value="#['Hello World!']" mimeType="text/plain"/>
</flow>
```

For MUnit to invoke that listener, enable the `http-example-flow` in your `enable-flow-source`
property within your MUnit test:

```xml
<http:request-config name="HTTP_Request_config">
    <http:request-connection host="localhost" port="1234"/>
</http:request-config>

<munit:test name="http-example-test">
    <munit:enable-flow-sources>
        <munit:enable-flow-source value="http-example-flow"/>
    </munit:enable-flow-sources>

    <munit:execution>
        <http:request method="GET" path="/" config-ref="HTTP_Request_config"/>
    </munit:execution>

    <munit:validation>
        <munit-tools:assert-that expression="#[payload]"
                                 is="#[MunitTools::equalTo('Hello World!')]"/>
    </munit:validation>
</munit:test>
```

If the `http-example-flow` value isn’t listed as an enabled flow source, your MUnit test fails
because it can’t initialize the HTTP listener configuration.

MUnit starts flow sources at the beginning of the test and stops them at the end of the test. Flow
sources aren’t executed during the before-suite/before-test, nor during the
after-test/after-suite.  
See [Before/After scopes](https://docs.mulesoft.com/munit/3.6/before-after-scopes-reference) for additional information.

<!-- document id=7de46aa009d63597c3aacacb4a60de2ecc44afb11932545844eb3aad30b174c4 url=/mulesoft/current/en-us/munit/latest/enable-flow-sources-concept.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
keywords: munit, test, flow sources
---

# Enable Flow Sources in MUnit

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The MUnit Enable Flow Sources element specifies which flow sources, such as HTTP listeners and
triggers, start and run during a MUnit test. By default, MUnit does not start any event sources. You
must explicitly configure which ones to enable for each test.

Assume that your application has a flow with an HTTP listener that returns a specific payload:

```xml
<http:listener-config name="HTTP_Listener_config">
    <http:listener-connection host="localhost" port="1234"/>
</http:listener-config>

<flow name="http-example-flow">
    <http:listener path="/" config-ref="HTTP_Listener_config"/>
    <set-payload value="#['Hello World!']" mimeType="text/plain"/>
</flow>
```

For MUnit to invoke that listener, enable the `http-example-flow` in your `enable-flow-source`
property within your MUnit test:

```xml
<http:request-config name="HTTP_Request_config">
    <http:request-connection host="localhost" port="1234"/>
</http:request-config>

<munit:test name="http-example-test">
    <munit:enable-flow-sources>
        <munit:enable-flow-source value="http-example-flow"/>
    </munit:enable-flow-sources>

    <munit:execution>
        <http:request method="GET" path="/" config-ref="HTTP_Request_config"/>
    </munit:execution>

    <munit:validation>
        <munit-tools:assert-that expression="#[payload]"
                                 is="#[MunitTools::equalTo('Hello World!')]"/>
    </munit:validation>
</munit:test>
```

If the `http-example-flow` value isn’t listed as an enabled flow source, your MUnit test fails
because it can’t initialize the HTTP listener configuration.

MUnit starts flow sources at the beginning of the test and stops them at the end of the test. Flow
sources aren’t executed during the before-suite/before-test, nor during the
after-test/after-suite.  
See [Before/After scopes](https://docs.mulesoft.com/munit/latest/before-after-scopes-reference) for additional information.

<!-- document id=a4a3f6e01af32089d1f7b81448282798f8a8897c03bbf37c1c70911fa370ca8e url=/mulesoft/current/en-us/munit/2.3/fail-event-processor.md -->

---
product: MUnit
version: 2.3
---

# Fail Event Processor

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

The Fail Event Processor allows you to fail your test on purpose. This is useful to validate that a
test should fail if that point is reached.

```xml
<munit-tools:fail
  message="This should fail"/>
```

The message field is optional and defines the error message to print when the assertion fails. The
processor throws a `java.lang.AssertionError`.

<!-- document id=cfa764ed29dc1d4723d1fe9dc8266d83572ec5617b5fdd5587eb38ad3e009f5a url=/mulesoft/current/en-us/munit/3.6/fail-event-processor.md -->

---
product: MUnit
version: 3.6
---

# Fail Event Processor

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The Fail Event Processor allows you to fail your test on purpose. This is useful to validate that a
test should fail if that point is reached.

```xml
<munit-tools:fail
  message="This should fail"/>
```

The message field is optional and defines the error message to print when the assertion fails. The
processor throws a `java.lang.AssertionError`.

<!-- document id=87ba4f0db1a102fee27b59eb2b3301b40d9b2019fd14f4176ba532457f4a889b url=/mulesoft/current/en-us/munit/2.3/ftp-util.md -->

---
product: MUnit
version: 2.3
---

# FTP Utils

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

To test a piece of code that connects with an FTP server, you must install an FTP server in your
local environment to run the tests. You could also have a dedicated external FTP server for testing,
but your Maven project would not be portable — a third party would need to install the testing FTP
server to compile your project.

To make it easier for you to test FTP connections, MUnit allows you to implement an FTP server in
your local environment.

## Install the MUnit FTP Server Module

1.  From Anypoint Studio, go to the **Mule Palette** and **Search in Exchange…​**.

2.  In the search bar, look for **MUnit Utils FTP Server** and add the module to your project:

    ```xml
    <!-- Ftp Server Dependency -->
    <dependency>
        <groupId>com.mulesoft.munit.utils</groupId>
        <artifactId>munit-ftpserver-module</artifactId>
        <version>2.0.1</version>
        <classifier>mule-plugin</classifier>
        <scope>test</scope>
    </dependency>
    ```

    The MUnit FTP server artifact in your POM file must have the `test` scope.

## Attributes Reference

The FTP Server takes the following parameters:

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><code>name</code></p></div></div></td><td><div><div><p>Defines the configuration name of the FTP server.</p></div><div><p>This value must be unique.</p></div></div></td></tr><tr><td><div><div><p><code>port</code></p></div></div></td><td><div><div><p>Defines the port on which the FTP server listens.</p></div></div></td></tr><tr><td><div><div><p><code>anonymous</code></p></div></div></td><td><div><div><p>(Boolean) Sets anonymous access to the FTP server. If <code>anonymous</code> is set to <code>true</code>, you don’t need to set a password to access the FTP server when using the <code>anonymous</code> username.</p></div><div><p>The default value is <code>true</code>.</p></div></div></td></tr><tr><td><div><div><p><code>secure</code></p></div></div></td><td><div><div><p>(Boolean) Defines the FTP protocol. When the secure parameter is set to true, the server behaves as an SFTP server and connections are allowed only through authentication. If this parameter is set to false, the server behaves as an FTP server and allows either authenticated or anonymous connections.</p></div><div><p>The default value is false.</p></div></div></td></tr><tr><td><div><div><p><code>homeDir</code></p></div></div></td><td><div><div><p>Defines the user home directory. The default value is the filesystem root.<br>It is possible to define the FTP user home directory using the <code>~</code> character to represent the home directory on the file system.</p></div></div></td></tr></tbody></table>

## MUnit FTP server Processors

The FTP Utility has two processors to interact with your FTP server:

contains-files

The `contains-files` processor attempts to validate the existence of a file in the FTP server. If
the file is not present, the processor fails causing the test to fail.

```xml
<ftpserver:contains-files config-ref="MUnit_FTP_Server_Config" path="/" file="example.txt"/>
```

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>config-ref</code></p></td><td><p>Defines the FTP server configuration.</p></td></tr><tr><td><p><code>path</code></p></td><td><p>Defines in which folder to search based on the user home directory defined previously.</p></td></tr><tr><td><p><code>file</code></p></td><td><p>Defines the name of the file to look for.</p></td></tr></tbody></table>

remove

The `remove` processor provides another operation that may be of use. This operation instructs the
FTP server to remove a file from storage.

```xml
<ftpserver:remove config-ref="MUnit_FTP_Server_Config" path="example.txt"/>
```

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>config-ref</code></p></td><td><p>Defines the FTP server configuration.</p></td></tr><tr><td><p><code>path</code></p></td><td><p>The full path of the file to remove.</p></td></tr></tbody></table>

This feature is useful when creating the same file name several times. You can configure it in
`after-test` to ensure that no name collisions cause the test to fail.

## See Also

- [Configuring FTP Server Utility in an MUnit Test](https://docs.mulesoft.com/munit/2.3/ftp-server-cookbook)

<!-- document id=97e99e266444bbc2015ac989f172a982e7ce8db72a9acb8e835bda2815c71684 url=/mulesoft/current/en-us/munit/3.6/ftp-util.md -->

---
product: MUnit
version: 3.6
---

# FTP Utils

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

To test a piece of code that connects with an FTP server, install an FTP server in your local
environment to run the tests. You can also use a dedicated external FTP server for testing, but your
Maven project can’t be portable. A third party must install the testing FTP server to compile your
project.

To test the FTP connections, you can implement an FTP server in your local environment with MUnit.

## Install the MUnit FTP Server Module

To install the MUnit FTP server module:

1.  Look for the **MUnit Utils FTP Server** module.

2.  Add the module to your project:

    ```xml
    <!-- Ftp Server Dependency -->
    <dependency>
        <groupId>com.mulesoft.munit.utils</groupId>
        <artifactId>munit-ftpserver-module</artifactId>
        <version>LATEST_VERSION</version> (1)
        <classifier>mule-plugin</classifier>
        <scope>test</scope>
    </dependency>
    ```

    <table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Check the <a href="https://repository.mulesoft.org/nexus/content/repositories/releases/com/mulesoft/munit/utils/munit-ftpserver-module/">MuleSoft Nexus repository</a> to get the <strong>LATEST_VERSION</strong>.</td></tr></tbody></table>

The MUnit FTP server artifact in your POM file must have the `test` scope.

> [!NOTE] The **MUnit FTP Server** module is located at
> [MuleSoft Nexus repository](https://repository.mulesoft.org/nexus/content/repositories/releases/com/mulesoft/munit/utils/munit-ftpserver-module/).
> The **MUnit FTP Server** module version 3 and later is compatible with Java 17. Previous versions
> of this module available at Anypoint Exchange are deprecated.

## Attributes Reference

The FTP server module takes the following parameters:

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><code>name</code></p></div></div></td><td><div><div><p>Defines the configuration name of the FTP server.<br>This value must be unique.</p></div></div></td></tr><tr><td><div><div><p><code>port</code></p></div></div></td><td><div><div><p>Defines the port on which the FTP server listens.</p></div></div></td></tr><tr><td><div><div><p><code>anonymous</code></p></div></div></td><td><div><div><p>(Boolean) Sets anonymous access to the FTP server. If you set <code>anonymous</code> to <code>true</code>, don’t set a password to access the FTP server when using the <code>anonymous</code> username.<br>The default value is <code>true</code>.</p></div></div></td></tr><tr><td><div><div><p><code>secure</code></p></div></div></td><td><div><div><p>(Boolean) Defines the FTP protocol. If you set the <code>secure</code> parameter to <code>true</code>, the server behaves as an SFTP server and connections must be authenticated. If you set the <code>secure</code> parameter to <code>false</code>, the server behaves as an FTP server and allows either authenticated or anonymous connections.<br>The default value is <code>false</code>.</p></div></div></td></tr><tr><td><div><div><p><code>homeDir</code></p></div></div></td><td><div><div><p>Defines the user’s home directory. The default value is the filesystem root.<br>You can define the FTP user home directory by using the <code>~</code> character to represent the home directory on the file system.</p></div></div></td></tr></tbody></table>

## MUnit FTP Server Processors

The FTP Utility has two processors to interact with your FTP server:

contains-files

The `contains-files` processor validates the existence of a file in the FTP server. If there is no
file present, the processor fails causing the test to fail.

```xml
<ftpserver:contains-files config-ref="MUnit_FTP_Server_Config" path="/" file="example.txt"/>
```

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>config-ref</code></p></td><td><p>Defines the FTP server configuration.</p></td></tr><tr><td><p><code>path</code></p></td><td><p>Defines in which folder to search based on the user home directory defined.</p></td></tr><tr><td><p><code>file</code></p></td><td><p>Defines the name of the file to look for.</p></td></tr></tbody></table>

remove

The `remove` processor provides an operation that instructs the FTP server to remove a file from
storage.

```xml
<ftpserver:remove config-ref="MUnit_FTP_Server_Config" path="example.txt"/>
```

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>config-ref</code></p></td><td><p>Defines the FTP server configuration.</p></td></tr><tr><td><p><code>path</code></p></td><td><p>Defines the full path of the file to remove.</p></td></tr></tbody></table>

This feature is useful when creating the same file name several times. You can configure it in
`after-test` to ensure that no name collisions cause the test to fail.

## See Also

- [Configuring FTP Server Utility in an MUnit Test](https://docs.mulesoft.com/munit/3.6/ftp-server-cookbook)

<!-- document id=ca243ba93a27e7dea8cadffd7e22f4ed455db70f2051c3e40ec0b8018b192717 url=/mulesoft/current/en-us/munit/latest/db-util.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# Install the MUnit Database Server Module

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

Install the MUnit Database Server module to run MUnit tests against an in-memory H2 database without
an external database server. This makes your Maven project portable and your database tests isolated
and repeatable.

## Install the MUnit DB Server Module

To install the MUnit DB Server Module:

1.  Look for the **MUnit Utils Database Server** module.

2.  Add the module to your project in the `pom.xml` file:

    ```xml
    <!-- dbserver Dependency -->
    <dependency>
        <groupId>com.mulesoft.munit.utils</groupId>
        <artifactId>munit-dbserver-module</artifactId>
        <version>LATEST_VERSION</version> (1)
        <classifier>mule-plugin</classifier>
        <scope>test</scope>
    </dependency>
    ```

    <table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Check the <a href="https://repository.mulesoft.org/nexus/content/repositories/releases/com/mulesoft/munit/utils/munit-dbserver-module/">MuleSoft Nexus repository</a> to get the <strong>LATEST_VERSION</strong>.<div><p>The MUnit DB server artifact in your <code>pom.xml</code> file must have the <code>test</code> scope.</p></div></td></tr></tbody></table>

3.  The `h2` dependency used for the database is a shared library.  
    Add the dependency to your `pom.xml` file and list it as a `sharedLibrary` in
    `mule-maven-plugin`.

    ```xml
    <!--Third party libs-->
    <dependency>
        <groupId>com.h2database</groupId>
        <artifactId>h2</artifactId>
        <version>1.3.166</version>
    </dependency>
    ```

    ```xml
    <plugin>
        <groupId>org.mule.tools.maven</groupId>
        <artifactId>mule-maven-plugin</artifactId>
        <version>${mule.maven.plugin.version}</version>
        <extensions>true</extensions>
        <configuration>
        <sharedLibraries>
                ...
                <sharedLibrary>
                    <groupId>com.h2database</groupId>
                    <artifactId>h2</artifactId>
                </sharedLibrary>
            </sharedLibraries>
        </configuration>
    </plugin>
    ```

> [!NOTE] The **MUnit DB Server** module is located at
> [MuleSoft Nexus repository](https://repository.mulesoft.org/nexus/content/repositories/releases/com/mulesoft/munit/utils/munit-dbserver-module/).
> The **MUnit DB Server** module version 3 and later is compatible with Java 17. Previous versions
> of this module available at Anypoint Exchange are deprecated.

## Attributes Reference

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>name</code></p></td><td><p>Defines the configuration name of this DB server. This value must be unique.</p></td></tr><tr><td><p><code>database</code></p></td><td><p>Defines the name of the in-memory DB.</p></td></tr><tr><td><p><code>sqlFile</code></p></td><td><p>Specifies the path of the SQL file that defines the DB structure/contents. Use this parameter to create the DB at startup. See the <a href="#db-structure-sql">Defining the DB Structure from an SQL File</a> section for additional information.</p></td></tr><tr><td><p><code>csv</code></p></td><td><p>Specifies the path of the comma-separated file used to define the DB structure/contents. Use this parameter to create the DB at startup. See <a href="#db-structure-csv">Defining the DB Structure from a CSV File</a> section for additional information.</p></td></tr><tr><td><p><code>connectionStringParameters</code></p></td><td><p>Defines the connection string for your database. You can concatenate the parameters with a semicolon.</p></td></tr></tbody></table>

## Define the DB Structure

You can define the structure and content of your database in two different ways:

- SQL

- CSV

The MUnit DB server is based on H2. Complex structures, index and join commands can present issues.

### Define the DB Structure from an SQL File

To define the DB structure and content from an SQL file, you must provide a valid set of ANSI SQL
DDL (Data Definition Language) instructions in your MUnit suite file. For example,
`my-munit-suite.xml`.

```xml
<dbserver:config name="MUnit_DB_Server_Config" >
    <dbserver:connection sqlFile="FILE_NAME.sql" database="DATABASE_NAME" connectionStringParameters="MODE=MySQL" />
</dbserver:config>
```

### Define the DB Structure from a CSV File

To define your DB structure in your MUnit suite file based on a CSV file:

- The name of the table is the name of the file (in the following example, `customers`).

- The names of the columns are the headers of your CSV file.

```xml
<dbserver:config name="MUnit_DB_Server_Config" >
    <dbserver:connection csv="FILE_NAME.csv" database="DATABASE_NAME" connectionStringParameters="MODE=MySQL" />
</dbserver:config>
```

You can also split your DB structure among several CSV files. In your MUnit suite file, include the
file names in a list, with the names separated by semicolons:

```xml
<dbserver:config name="MUnit_DB_Server_Config" >
    <dbserver:connection csv="FILE_NAME.csv;FILE_NAME_1.csv" database="DATABASE_NAME" connectionStringParameters="MODE=MySQL" />
</dbserver:config>
```

This creates two tables: `FILE_NAME` and `FILE_NAME_1`.

## MUnit DB Server Processors

The DB server utility has two processors to interact with your DB server:

### Validate-That

To validate that the results of a query are as expected, use the `validate-that` operation in your
MUnit suite file. Set the `results` property to CSV with rows separated by a newline character
(`\n`), as follows:

```xml
<dbserver:validate-that config-ref="DB_Server"
query="SELECT * FROM jobtitlelookup WHERE JOBTITLE='Developer';" returns="&quot;JOBTITLE&quot;,&quot;EECSALARYORHOURLY&quot;,&quot;JOBTITLEID&quot;\n&quot;Developer&quot;,&quot;10&quot;,&quot;DEV&quot;" />
```

### Execute

Execute instructions for the in-memory databases to add or remove registries before a test and
verify that your data is correctly stored using MUnit DB Server.

In your MUnit suite file, use a DB Server connector with the `execute` operation to insert the new
values to the table (`Culinary Team Member,10,HIR`). Then use another DB Server connector with an
`execute query` operation to retrieve all values from the table (including the newly added ones).
Finally, check the payload using a logger component to store the payload:

```xml
<!-- Execute a SQL instruction using the execute operation -->
<dbserver:execute config-ref="MUnit_DB_Server_Config" sql="INSERT INTO jobtitlelookup VALUES ('Culinary Team Member','10','HIR');"/>

<!-- Check the update using execute-query operation -->
<dbserver:execute-query config-ref="MUnit_DB_Server_Config" sql="SELECT * FROM jobtitlelookup"/>

<!-- log the resulting payload -->
<logger level="INFO" message="#[payload]"/>
```

The logger in your console reads:

```text
org.mule.runtime.core.internal.processor.LoggerMessageProcessor: [{JOBTITLEID=DEV, EECSALARYORHOURLY=10, JOBTITLE=Developer}, {JOBTITLEID=HIR, EECSALARYORHOURLY=10, JOBTITLE=Culinary Team Member}]
```

## See Also

- [Configuring DB Server Utility in an MUnit Test](https://docs.mulesoft.com/munit/latest/db-server-cookbook)

<!-- document id=9deb43b6917a8f09f5fd9f9573cd2309ceae2fd7863a85540a6d8cdd2e176081 url=/mulesoft/current/en-us/munit/latest/ftp-util.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# Install the MUnit FTP Server Module

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

Install the MUnit FTP Server module to run MUnit tests against an in-memory FTP or SFTP server
without an external server. This makes your Maven project portable and your FTP-based tests isolated
and repeatable.

## Install the MUnit FTP Server Module

To install the MUnit FTP server module:

1.  Look for the **MUnit Utils FTP Server** module.

2.  Add the module to your project:

    ```xml
    <!-- Ftp Server Dependency -->
    <dependency>
        <groupId>com.mulesoft.munit.utils</groupId>
        <artifactId>munit-ftpserver-module</artifactId>
        <version>LATEST_VERSION</version> (1)
        <classifier>mule-plugin</classifier>
        <scope>test</scope>
    </dependency>
    ```

    <table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Check the <a href="https://repository.mulesoft.org/nexus/content/repositories/releases/com/mulesoft/munit/utils/munit-ftpserver-module/">MuleSoft Nexus repository</a> to get the <strong>LATEST_VERSION</strong>.</td></tr></tbody></table>

The MUnit FTP server artifact in your POM file must have the `test` scope.

> [!NOTE] The **MUnit FTP Server** module is located at
> [MuleSoft Nexus repository](https://repository.mulesoft.org/nexus/content/repositories/releases/com/mulesoft/munit/utils/munit-ftpserver-module/).
> The **MUnit FTP Server** module version 3 and later is compatible with Java 17. Previous versions
> of this module available at Anypoint Exchange are deprecated.

## Attributes Reference

The FTP server module takes the following parameters:

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><code>name</code></p></div></div></td><td><div><div><p>Defines the configuration name of the FTP server.<br>This value must be unique.</p></div></div></td></tr><tr><td><div><div><p><code>port</code></p></div></div></td><td><div><div><p>Defines the port on which the FTP server listens.</p></div></div></td></tr><tr><td><div><div><p><code>anonymous</code></p></div></div></td><td><div><div><p>(Boolean) Sets anonymous access to the FTP server. If you set <code>anonymous</code> to <code>true</code>, don’t set a password to access the FTP server when using the <code>anonymous</code> username.<br>The default value is <code>true</code>.</p></div></div></td></tr><tr><td><div><div><p><code>secure</code></p></div></div></td><td><div><div><p>(Boolean) Defines the FTP protocol. If you set the <code>secure</code> parameter to <code>true</code>, the server behaves as an SFTP server and connections must be authenticated. If you set the <code>secure</code> parameter to <code>false</code>, the server behaves as an FTP server and allows either authenticated or anonymous connections.<br>The default value is <code>false</code>.</p></div></div></td></tr><tr><td><div><div><p><code>homeDir</code></p></div></div></td><td><div><div><p>Defines the user’s home directory. The default value is the filesystem root.<br>You can define the FTP user home directory by using the <code>~</code> character to represent the home directory on the file system.</p></div></div></td></tr></tbody></table>

## MUnit FTP Server Processors

The FTP Utility has two processors to interact with your FTP server:

contains-files

The `contains-files` processor validates the existence of a file in the FTP server. If there is no
file present, the processor fails causing the test to fail.

```xml
<ftpserver:contains-files config-ref="MUnit_FTP_Server_Config" path="/" file="example.txt"/>
```

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>config-ref</code></p></td><td><p>Defines the FTP server configuration.</p></td></tr><tr><td><p><code>path</code></p></td><td><p>Defines in which folder to search based on the user home directory defined.</p></td></tr><tr><td><p><code>file</code></p></td><td><p>Defines the name of the file to look for.</p></td></tr></tbody></table>

remove

The `remove` processor provides an operation that instructs the FTP server to remove a file from
storage.

```xml
<ftpserver:remove config-ref="MUnit_FTP_Server_Config" path="example.txt"/>
```

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>config-ref</code></p></td><td><p>Defines the FTP server configuration.</p></td></tr><tr><td><p><code>path</code></p></td><td><p>Defines the full path of the file to remove.</p></td></tr></tbody></table>

This feature is useful when creating the same file name several times. You can configure it in
`after-test` to ensure that no name collisions cause the test to fail.

## See Also

- [Configuring FTP Server Utility in an MUnit Test](https://docs.mulesoft.com/munit/latest/ftp-server-cookbook)

<!-- document id=2c12c81f36e91b49f0c725dc0cb05f84e779b99712b6b2a0fa056ed14bfb00e1 url=/mulesoft/current/en-us/munit/3.6/db-util.md -->

---
product: MUnit
version: 3.6
---

# Installing a Database Server

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

To test a piece of code that connects with a database server, install a database server in your
local environment to run the tests. You can also use a dedicated external database server for
testing, but your Maven project can’t be portable. If so, a third party must install the testing
database server to compile your project.

To make it easier for you to test database connections, MUnit allows you to implement a database
server in your local environment.

## Install the MUnit DB Server Module

To install the MUnit DB Server Module:

1.  Look for the **MUnit Utils Database Server** module.

2.  Add the module to your project in the `pom.xml` file:

    ```xml
    <!-- dbserver Dependency -->
    <dependency>
        <groupId>com.mulesoft.munit.utils</groupId>
        <artifactId>munit-dbserver-module</artifactId>
        <version>LATEST_VERSION</version> (1)
        <classifier>mule-plugin</classifier>
        <scope>test</scope>
    </dependency>
    ```

    <table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Check the <a href="https://repository.mulesoft.org/nexus/content/repositories/releases/com/mulesoft/munit/utils/munit-dbserver-module/">MuleSoft Nexus repository</a> to get the <strong>LATEST_VERSION</strong>.<div><p>The MUnit DB server artifact in your <code>pom.xml</code> file must have the <code>test</code> scope.</p></div></td></tr></tbody></table>

3.  The `h2` dependency used for the database is a shared library.  
    Add the dependency to your `pom.xml` file and list it as a `sharedLibrary` in
    `mule-maven-plugin`.

    ```xml
    <!--Third party libs-->
    <dependency>
        <groupId>com.h2database</groupId>
        <artifactId>h2</artifactId>
        <version>1.3.166</version>
    </dependency>
    ```

    ```xml
    <plugin>
        <groupId>org.mule.tools.maven</groupId>
        <artifactId>mule-maven-plugin</artifactId>
        <version>${mule.maven.plugin.version}</version>
        <extensions>true</extensions>
        <configuration>
        <sharedLibraries>
                ...
                <sharedLibrary>
                    <groupId>com.h2database</groupId>
                    <artifactId>h2</artifactId>
                </sharedLibrary>
            </sharedLibraries>
        </configuration>
    </plugin>
    ```

> [!NOTE] The **MUnit DB Server** module is located at
> [MuleSoft Nexus repository](https://repository.mulesoft.org/nexus/content/repositories/releases/com/mulesoft/munit/utils/munit-dbserver-module/).
> The **MUnit DB Server** module version 3 and later is compatible with Java 17. Previous versions
> of this module available at Anypoint Exchange are deprecated.

## Attributes Reference

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>name</code></p></td><td><p>Defines the configuration name of this DB server. This value must be unique.</p></td></tr><tr><td><p><code>database</code></p></td><td><p>Defines the name of the in-memory DB.</p></td></tr><tr><td><p><code>sqlFile</code></p></td><td><p>Specifies the path of the SQL file that defines the DB structure/contents. Use this parameter to create the DB at startup. See the <a href="#db-structure-sql">Defining the DB Structure from an SQL File</a> section for additional information.</p></td></tr><tr><td><p><code>csv</code></p></td><td><p>Specifies the path of the comma-separated file used to define the DB structure/contents. Use this parameter to create the DB at startup. See <a href="#db-structure-csv">Defining the DB Structure from a CSV File</a> section for additional information.</p></td></tr><tr><td><p><code>connectionStringParameters</code></p></td><td><p>Defines the connection string for your database. You can concatenate the parameters with a semicolon.</p></td></tr></tbody></table>

## Define the DB Structure

You can define the structure and content of your database in two different ways:

- SQL

- CSV

The MUnit DB server is based on H2. Complex structures, index and join commands can present issues.

### Defining the DB Structure from an SQL File

To define the DB structure and content from an SQL file, you must provide a valid set of ANSI SQL
DDL (Data Definition Language) instructions in your MUnit suite file. For example,
`my-munit-suite.xml`.

```xml
<dbserver:config name="MUnit_DB_Server_Config" >
    <dbserver:connection sqlFile="FILE_NAME.sql" database="DATABASE_NAME" connectionStringParameters="MODE=MySQL" />
</dbserver:config>
```

### Define the DB Structure From a CSV File

To define your DB structure in your MUnit suite file based on a CSV file:

- The name of the table is the name of the file (in the following example, `customers`).

- The names of the columns are the headers of your CSV file.

```xml
<dbserver:config name="MUnit_DB_Server_Config" >
    <dbserver:connection csv="FILE_NAME.csv" database="DATABASE_NAME" connectionStringParameters="MODE=MySQL" />
</dbserver:config>
```

You can also split your DB structure among several CSV files. In your MUnit suite file, include the
file names in a list, with the names separated by semicolons:

```xml
<dbserver:config name="MUnit_DB_Server_Config" >
    <dbserver:connection csv="FILE_NAME.csv;FILE_NAME_1.csv" database="DATABASE_NAME" connectionStringParameters="MODE=MySQL" />
</dbserver:config>
```

This creates two tables: `FILE_NAME` and `FILE_NAME_1`.

## MUnit DB Server Processors

The DB server utility has two processors to interact with your DB server:

### Validate-That

To validate that the results of a query are as expected, use the `validate-that` operation in your
MUnit suite file. Set the `results` property to CSV with rows separated by a newline character
(`\n`), as follows:

```xml
<dbserver:validate-that config-ref="DB_Server"
query="SELECT * FROM jobtitlelookup WHERE JOBTITLE='Developer';" returns="&quot;JOBTITLE&quot;,&quot;EECSALARYORHOURLY&quot;,&quot;JOBTITLEID&quot;\n&quot;Developer&quot;,&quot;10&quot;,&quot;DEV&quot;" />
```

### Execute

Execute instructions for the in-memory databases to add or remove registries before a test and
verify that your data is correctly stored using MUnit DB Server.

In your MUnit suite file, use a DB Server connector with the `execute` operation to insert the new
values to the table (`Culinary Team Member,10,HIR`). Then use another DB Server connector with an
`execute query` operation to retrieve all values from the table (including the newly added ones).
Finally, check the payload using a logger component to store the payload:

```xml
<!-- Execute a SQL instruction using the execute operation -->
<dbserver:execute config-ref="MUnit_DB_Server_Config" sql="INSERT INTO jobtitlelookup VALUES ('Culinary Team Member','10','HIR');"/>

<!-- Check the update using execute-query operation -->
<dbserver:execute-query config-ref="MUnit_DB_Server_Config" sql="SELECT * FROM jobtitlelookup"/>

<!-- log the resulting payload -->
<logger level="INFO" message="#[payload]"/>
```

The logger in your console reads:

```text
org.mule.runtime.core.internal.processor.LoggerMessageProcessor: [{JOBTITLEID=DEV, EECSALARYORHOURLY=10, JOBTITLE=Developer}, {JOBTITLEID=HIR, EECSALARYORHOURLY=10, JOBTITLE=Culinary Team Member}]
```

## See Also

- [Configuring DB Server Utility in an MUnit Test](https://docs.mulesoft.com/munit/3.6/db-server-cookbook)

<!-- document id=5b8d2847e4b305bf0dda21349a70db96e9374ae61669e14be30c1a7a6aa0ee7a url=/mulesoft/current/en-us/munit/2.3/iterable-map-matchers-reference.md -->

---
product: MUnit
version: 2.3
---

# Iterable and Map Matchers Reference

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

## everyItem(Matcher)

Checks that every element in the expression matches the specified matcher.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::everyItem(MunitTools::notNullValue())]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::everyItem(MunitTools::startsWith('a'))]"/>
```

## hasItem(Object)

Checks that any element in the expression matches the specified matcher.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasItem('example')]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasItem(MunitTools::startsWith('a'))]"/>
```

## hasSize(Matcher|Integer)

Checks that the size of the expression matches the specified matcher.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasSize(MunitTools::greaterThan(2))]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasSize(5)]"/>
```

## isEmpty()

Checks that the expression is an empty collection.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::isEmpty()]"/>
```

## hasKey(Matcher|String)

Checks that the expression has a key that matches the specified matcher.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasKey(MunitTools::startsWith('a'))]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasKey('mykey')]"/>
```

## hasValue(Object)

Checks that the expression has a value that matches the specified matcher.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasValue('myvalue')]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasValue(MunitTools::startsWith('a'))]"/>
```

## See Also

- [MUnit Matchers](https://docs.mulesoft.com/munit/2.3/munit-matchers)

- [Core Matchers Reference](https://docs.mulesoft.com/munit/2.3/core-matchers-reference)

- [String Matchers Reference](https://docs.mulesoft.com/munit/2.3/string-matchers-reference)

- [Comparable Matchers Reference](https://docs.mulesoft.com/munit/2.3/comparable-matchers-reference)

<!-- document id=971ac238d5045259e09e5aad16e9d01f6309ff96e555983ae992ad3d0b9a8c90 url=/mulesoft/current/en-us/munit/3.6/iterable-map-matchers-reference.md -->

---
product: MUnit
version: 3.6
---

# Iterable and Map Matchers Reference

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

## everyItem(Matcher)

Checks that every element in the expression matches the specified matcher.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::everyItem(MunitTools::notNullValue())]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::everyItem(MunitTools::startsWith('a'))]"/>
```

## hasItem(Object)

Checks that any element in the expression matches the specified matcher.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasItem('example')]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasItem(MunitTools::startsWith('a'))]"/>
```

## hasSize(Matcher|Integer)

Checks that the size of the expression matches the specified matcher.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasSize(MunitTools::greaterThan(2))]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasSize(5)]"/>
```

## isEmpty()

Checks that the expression is an empty collection.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::isEmpty()]"/>
```

## hasKey(Matcher|String)

Checks that the expression has a key that matches the specified matcher.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasKey(MunitTools::startsWith('a'))]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasKey('mykey')]"/>
```

## hasValue(Object)

Checks that the expression has a value that matches the specified matcher.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasValue('myvalue')]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasValue(MunitTools::startsWith('a'))]"/>
```

## See Also

- [MUnit Matchers](https://docs.mulesoft.com/munit/3.6/munit-matchers)

- [Core Matchers Reference](https://docs.mulesoft.com/munit/3.6/core-matchers-reference)

- [String Matchers Reference](https://docs.mulesoft.com/munit/3.6/string-matchers-reference)

- [Comparable Matchers Reference](https://docs.mulesoft.com/munit/3.6/comparable-matchers-reference)

<!-- document id=e7dd3a06760b5c5567f08d581a8640ccdaef10e8df0b035aa2850b9c3d4b3e00 url=/mulesoft/current/en-us/munit/2.3/coverage-maven-concept.md -->

---
product: MUnit
version: 2.3
---

# Maven Configuration for Coverage

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

Since MUnit 2.x, the coverage report goal is integrated with the maven reporting section. Coverage
Reports are generated during Maven’s `site` lifecycle, during the `coverage-report` goal.

The following configurations apply only when you execute your MUnit tests using the Maven plugin.
They do not apply when running tests from Studio.  
To run coverage reports in Studio see [Using Coverage in Studio](https://docs.mulesoft.com/munit/2.3/coverage-studio-concept).

MUnit Coverage - Sample Maven configuration

```xml
<plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <version>${munit.version}</version>

    <executions>
        <execution>
            <id>test</id>
            <phase>test</phase>
            <goals>
                <goal>test</goal>
                <goal>coverage-report</goal>
            </goals>
        </execution>
    </executions>

    <configuration>
        <coverage>
            <runCoverage>true</runCoverage>
            <failBuild>false</failBuild>

            <requiredApplicationCoverage>75</requiredApplicationCoverage>
            <requiredResourceCoverage>50</requiredResourceCoverage>
            <requiredFlowCoverage>50</requiredFlowCoverage>

            <formats>
                <format>console</format>
                <format>html</format>
            </formats>
        </coverage>
    </configuration>
</plugin>
```

## Coverage Report Types

When enabling MUnit Coverage, you see a summary report in the console. By default, no other action
is taken:

```console
===============================================================================
MUnit Coverage Summary
===============================================================================
 * Resources: 2 - Flows: 3 - Processors: 4
 * Application Coverage: 75.00%
====================================================================================
```

MUnit Coverage offers four types of reports:

- Console report  
  The console report is printed to the console. It works with the summary report and shows an
  overview of the MUnit run, with a count of all resources, flows, and processors, as well as the
  overall application coverage level, and warnings and errors if any.

- HTML report  
  The HTML report shows the same information as the console report, but formatted to fit any web
  browser. It is available in the `${application.path}/target/site/munit/coverage/` path.+

- JSON report The JSON report shows the same information as the HTML report, but in a JSON format.
  It is available in the `${application.path}/target/site/munit/coverage/munit-coverage.json` path.+

- The SONAR report shows the same information as the HTML report, in a SonarQube format.

To enable the report generation, add the following configuration:

MUnit Coverage - Report Configuration

```xml
<coverage>
    <runCoverage>true</runCoverage>

    <formats>
        <format>console</format> (1)
        <format>html</format>    (2)
        <format>json</format>    (3)
        <format>sonar</format>   (4)
    </formats>
</coverage>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Console report</td></tr><tr><td><i data-value="2"></i><b>2</b></td><td>HTML report</td></tr><tr><td><i data-value="3"></i><b>3</b></td><td>JSON report</td></tr><tr><td><i data-value="4"></i><b>4</b></td><td>SONAR report</td></tr></tbody></table>

You can choose to have either none, one, or all the report types added to your configuration.

To configure, for example, the JSON report generation, you must to add the following configuration
to your `pom.xml` file:

```xml
<coverage>
    <runCoverage>true</runCoverage>

    <formats>
        <format>json</format>
    </formats>
</coverage>
```

## Set up a Minimum Coverage Level

One of the features of MUnit Coverage is to fail the build if a certain coverage level is not
reached.

MUnit Coverage handles three different levels:

- **Application**: The overall coverage of all your application.

- **Resource**: The coverage level of each individual Mule configuration file.

- **Flow**: The coverage of event processors in each flow.

To define the required coverage levels:

MUnit Coverage - Require Coverage

```xml
<coverage>
    <runCoverage>true</runCoverage>
    <failBuild>true</failBuild>

    <requiredApplicationCoverage>75</requiredApplicationCoverage> (1)
    <requiredResourceCoverage>50</requiredResourceCoverage>
    <requiredFlowCoverage>50</requiredFlowCoverage>
</coverage>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Each value represents a percentage.<br>If a percentage is not defined, it defaults to <strong>-1</strong>, which indicates that no requirements are defined for said level so the build will not fail due to low coverage.</td></tr></tbody></table>

If you define coverage levels but set the property `failBuild` to **false**, and then the levels are
not reached, a warning shows up in the MUnit coverage summary:

```console
===============================================================================
MUnit Coverage Summary
===============================================================================
 * Resources: 2 - Flows: 3 - Processors: 4
 * Application Coverage: 75.00%

----------------------------- WARNING --------------------------------------
 * Flow: file2.xml -> file2Flow1 coverage is below defined limit. Required: 50.0% - Current: 00.00% (1)
====================================================================================
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Warning detailing which coverage level was not met, and where it happened.</td></tr></tbody></table>

## Ignore a flow or a file

Another feature is the ability to ignore either a flow or a file. This way, the ignored resource:

- Does not count as coverage data.

- Does not affect the overall number of message processors.

- Does not cause a build to fail if the flow is not tested or if the flow does not reach coverage
  metrics.

To ignore flows and files:

MUnit Coverage - Ignore both flows and files

```xml
<coverage>
    <runCoverage>true</runCoverage>
    <failBuild>true</failBuild>

    <requiredApplicationCoverage>100</requiredApplicationCoverage>
    <requiredResourceCoverage>100</requiredResourceCoverage>
    <requiredFlowCoverage>100</requiredFlowCoverage>

    <ignoreFlows>
        <ignoreFlow>flow-1</ignoreFlow>
        <ignoreFlow>flow-2</ignoreFlow>
        ...
        <ignoreFlow>flow-n</ignoreFlow>
    </ignoreFlows>

    <ignoreFiles>
        <ignoreFile>mule-config-1.xml</ignoreFile>
        <ignoreFile>mule-config-2.xml</ignoreFile>
        ...
        <ignoreFile>mule-config-n.xml</ignoreFile>
    </ignoreFiles>
</coverage>
```

## See Also

- [Coverage Report](https://docs.mulesoft.com/munit/2.3/munit-coverage-report)

<!-- document id=682583499c8383d3e0ecce9c325a33e975ead29e4f3668fb66b59b43ea70c91d url=/mulesoft/current/en-us/munit/3.6/coverage-maven-concept.md -->

---
product: MUnit
version: 3.6
---

# Maven Configuration for Coverage

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

From MUnit 2.x and later, the coverage report goal is integrated with the Maven reporting section.
MUnit generates coverage reports during the Maven `site` lifecycle, during the `coverage-report`
goal.

The following configurations apply if you execute your MUnit tests using the Maven plugin. They
don’t apply when running tests from Anypoint Code Builder or Anypoint Studio.

MUnit Coverage - Sample Maven configuration

```xml
<plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <version>${munit.version}</version>

    <executions>
        <execution>
            <id>test</id>
            <phase>test</phase>
            <goals>
                <goal>test</goal>
                <goal>coverage-report</goal>
            </goals>
        </execution>
    </executions>

    <configuration>
        <coverage>
            <runCoverage>true</runCoverage>
            <failBuild>false</failBuild>

            <requiredApplicationCoverage>75</requiredApplicationCoverage>
            <requiredResourceCoverage>50</requiredResourceCoverage>
            <requiredFlowCoverage>50</requiredFlowCoverage>

            <formats>
                <format>console</format>
                <format>html</format>
            </formats>
        </coverage>
    </configuration>
</plugin>
```

## Coverage Report Types

When you enable MUnit Coverage, the console displays a summary report.

```console
===============================================================================
MUnit Coverage Summary
===============================================================================
 * Resources: 2 - Flows: 3 - Processors: 4
 * Application Coverage: 75.00%
====================================================================================
```

MUnit Coverage offers four types of reports:

- Console report  
  The console report prints in the console. It works with the summary report and shows an overview
  of the MUnit run, with a count of all resources, flows, and processors, as well as the overall
  application coverage level, and warnings and errors if any.

- HTML report  
  The HTML report shows the same information as the console report but is formatted to fit any web
  browser. It’s available in the `${application.path}/target/site/munit/coverage/` path.

- JSON report  
  The JSON report provides the same information as the HTML report but in a JSON format. It’s
  available at `${application.path}/target/site/munit/coverage/munit-coverage.json`.

- SONAR report  
  The SONAR report shows the same information as the HTML report, in a SonarQube format.

To enable the report generation, add the following configuration:

MUnit Coverage - Report Configuration

```xml
<coverage>
    <runCoverage>true</runCoverage>

    <formats>
        <format>console</format> (1)
        <format>html</format>    (2)
        <format>json</format>    (3)
        <format>sonar</format>   (4)
    </formats>
</coverage>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Console report</td></tr><tr><td><i data-value="2"></i><b>2</b></td><td>HTML report</td></tr><tr><td><i data-value="3"></i><b>3</b></td><td>JSON report</td></tr><tr><td><i data-value="4"></i><b>4</b></td><td>SONAR report</td></tr></tbody></table>

You can choose to have either none, one, or all the report types added to your configuration.

To configure, for example, the JSON report generation, add the following configuration to your
`pom.xml` file:

```xml
<coverage>
    <runCoverage>true</runCoverage>

    <formats>
        <format>json</format>
    </formats>
</coverage>
```

## Set up a Minimum Coverage Level

One of the features of MUnit Coverage is to fail the build if a certain coverage level isn’t
reached.

MUnit Coverage handles three different levels:

- **Application**: The overall coverage of all your application.

- **Resource**: The coverage level of each Mule configuration file.

- **Flow**: The coverage of event processors in each flow.

To define the required coverage levels:

MUnit Coverage - Require Coverage

```xml
<coverage>
    <runCoverage>true</runCoverage>
    <failBuild>true</failBuild>

    <requiredApplicationCoverage>75</requiredApplicationCoverage> (1)
    <requiredResourceCoverage>50</requiredResourceCoverage>
    <requiredFlowCoverage>50</requiredFlowCoverage>
</coverage>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Each value represents a percentage.<br>If a percentage isn’t defined, it defaults to <strong>-1</strong>, which sets no requirements for said level so the build doesn’t fail due to low coverage.</td></tr></tbody></table>

If you define coverage levels but set the property `failBuild` to `false`, and then the levels
aren’t reached, a warning shows up in the MUnit Coverage summary:

```console
===============================================================================
MUnit Coverage Summary
===============================================================================
 * Resources: 2 - Flows: 3 - Processors: 4
 * Application Coverage: 75.00%

----------------------------- WARNING --------------------------------------
 * Flow: file2.xml -> file2Flow1 coverage is below defined limit. Required: 50.0% - Current: 00.00% (1)
====================================================================================
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Warning detailing which coverage level isn’t met, and where it happens.</td></tr></tbody></table>

## Ignore a Flow or a File

You can also ignore a flow or a file. This way, the ignored resource:

- Does not count as coverage data.

- Does not affect the overall number of message processors.

- Does not cause a build to fail if the flow isn’t tested or if the flow doesn’t reach coverage
  metrics.

To ignore flows and files:

MUnit Coverage - Ignore flows and files

```xml
<coverage>
    <runCoverage>true</runCoverage>
    <failBuild>true</failBuild>

    <requiredApplicationCoverage>100</requiredApplicationCoverage>
    <requiredResourceCoverage>100</requiredResourceCoverage>
    <requiredFlowCoverage>100</requiredFlowCoverage>

    <ignoreFlows>
        <ignoreFlow>flow-1</ignoreFlow>
        <ignoreFlow>flow-2</ignoreFlow>
        ...
        <ignoreFlow>flow-n</ignoreFlow>
    </ignoreFlows>

    <ignoreFiles>
        <ignoreFile>mule-config-1.xml</ignoreFile>
        <ignoreFile>mule-config-2.xml</ignoreFile>
        ...
        <ignoreFile>mule-config-n.xml</ignoreFile>
    </ignoreFiles>
</coverage>
```

## See Also

- [Coverage Report](https://docs.mulesoft.com/munit/3.6/munit-coverage-report)

- [Using Coverage in Studio](https://docs.mulesoft.com/munit/3.6/coverage-studio-concept).

<!-- document id=06cbfbe4ff0fe550ac9c7d102409f95d004ca92b1b52243b0190a8ef1fa16dcc url=/mulesoft/current/en-us/munit/latest/mock-before-after-foreach-cookbook.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# Mock Messages Before and Inside a Foreach Processor in MUnit

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

Mock processors inside a foreach scope in MUnit to return different payloads on each iteration. Use
the mock-when processor with a then-call operation to delegate mock responses to a separate flow
that evaluates the foreach counter.

Suppose you have a processor inside a `foreach` scope and you want to provide different values on
each iteration:

```xml
<flow name="foreachFlow">
	<foreach doc:name="For Each">
		<flow-ref doc:name="Flow Reference" name="FlowToMock"/>
	</foreach>
</flow>
```

Use an `munit-tools:mock-when` processor to mock the processor in your flow and use the `then-call`
operation to call a new flow that set payloads depending on the `foreach` status:

```xml
<munit-tools:mock-when doc:name="Mock when" processor="flow-ref">
	<munit-tools:with-attributes >
		<munit-tools:with-attribute attributeName="name" whereValue="FlowToMock" />
	</munit-tools:with-attributes>
	<munit-tools:then-call flow="MockedFlow" />
</munit-tools:mock-when>
```

Inside the flow that is called by the `then-call` you can use a `Choice` processor to evaluate a
value and set a mocked payload. In this case, the `foreach` counter is evaluated to decide which
payload to set:

```xml
<flow name="MockedFlow" >
	<choice doc:name="Choice">
		<when expression="#[vars.counter == 1]">
			<set-payload value='#["MOCKED1"]' doc:name="Set Payload" />
		</when>
		<when expression="#[vars.counter == 2]">
			<set-payload value='#["MOCKED2"]' doc:name="Set Payload" />
		</when>
		<otherwise >
			<set-payload value='#["DEFAULT"]' doc:name="Set Payload" />
		</otherwise>
	</choice>
</flow>
```

## Mock a Mule Message

To mock processors like `file:list` or `ftp:list`, you must return a Mule message collection as
payload. `MunitTools` provides a function to mock these payloads:

```none
fun createMessage(payload: Any, attributes: Any = null)

fun createMessage(payload: Any, mimeType: String|Null , attributes: Any, attributeMimeType: String|Null)
```

```xml
<flow doc:name="Flow" >
	<file:list doc:name="List" config-ref="File_Config" directoryPath="/tmp/"/>
</flow>

<munit-tools:mock-when processor="file:list">
   <munit-tools:with-attributes>
       <munit-tools:with-attribute attributeName="doc:name" whereValue="List"/>
   </munit-tools:with-attributes>
   <munit-tools:then-return>
       <munit-tools:payload value="#[[MunitTools::createMessage( &quot;ITEM-1&quot;,  &quot;text/plain&quot;, { property : 'ATTRIBUTE-1'}, null) , MunitTools::createMessage( &quot;ITEM-2&quot;,  &quot;text/plain&quot;, { property : 'ATTRIBUTE-2'}, null)]]" />
   </munit-tools:then-return>
</munit-tools:mock-when>
```

## See Also

- [Mock When Event Processor](https://docs.mulesoft.com/munit/latest/mock-event-processor)

<!-- document id=700248cbeb08f42177a99170c713eb1e835eab19a3e806f79f00f307df44cfa7 url=/mulesoft/current/en-us/munit/latest/mock-file-cookbook.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# Mock Resources for MUnit Tests with DataWeave

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

Externalize mock data for MUnit tests using DataWeave scripts or modules to keep your test code
clean and reusable. Use DataWeave files or variables in a DataWeave module to centralize mocked
payloads and responses.

## Mock Files Using DataWeave File

You can write a DataWeave file that returns the data that you want to mock, save the file under a
folder in `src/test/resources` and then use a DataWeave function from your test to read this file.

For example, imagine that you have defined a `mockPost.dwl` file in the
`src/test/resources/sample_data` folder with the following content:

```none
%dw 2.0
output application/json
---
{
	"foo" : "var"
}
```

This DataWeave file (`mockPost.dwl`) is a sample that creates a mock payload that you want to return
in an `http:request` request.

When configuring the `then-return` section in the `mock-when`, use the `readUrl` function to read
the mapping file:

```xml
<munit-tools:then-return>
  <munit-tools:payload value="#[readUrl('classpath://sample_data/mockPost.dwl')]" mediaType="application/json" encoding="UTF-8" />
</munit-tools:then-return>
```

The `classpath-based` URL uses the `classpath:` protocol prefix to find the file defined in
`src/test/resources`.

## Mock Files Using Variables in a DataWeave Module

You can create a DataWeave module to centralize all your mocked data in a single file by declaring
it using DataWeave variables.

For example, imagine that you create a custom DataWeave module by creating a `TestData.dwl` file in
`src/test/resources`, and you add variables with references to different mocked data, either from
files or inline:

```none
import getResourceAsString from MunitTools

var mockPost = readUrl('classpath://sample_data/mockPost.dwl')
var foo = "N123"
var jsonFromFile = read(getResourceAsString('sample_data/mydata.json'), 'application/json')
var jsonObject = { paymentID: "1B56925769601335TLQMIWVY" }
```

You can then access any of the defined variables in the DataWeave module by importing the variables
from your module:

```xml
<munit-tools:then-return >
    <munit-tools:variables>
        <munit-tools:variable key="ticket" value="#[import TestData output application/json --- TestData::mockPost]" mediaType="application/json" />
    </munit-tools:variables>
</munit-tools:then-return>
```

## See Also

- [Create Custom Modules and Mappings](https://docs.mulesoft.com/dataweave/latest/dataweave-create-module)

<!-- document id=17cec7f6f1005988bcfc5e26a72595d0c8a14e12306c266ae7886f12dd75fd0c url=/mulesoft/current/en-us/munit/2.3/mock-event-processor.md -->

---
product: MUnit
version: 2.3
keywords: munit, testing, unit testing
---

# Mock When Event Processor

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

The **Mock When** processor enables you to mock an event processor when it matches the defined name
and attributes.

For example, you can use the **Mock Event** processor to mock a POST request with a mocked payload:

```xml
<munit-tools:mock-when processor="http:request">
   <munit-tools:with-attributes>
       <munit-tools:with-attribute attributeName="method" whereValue="#['POST']"/>
   </munit-tools:with-attributes>
   <munit-tools:then-return>
       <munit-tools:payload value="#['mockPayload']"/>
   </munit-tools:then-return>
</munit-tools:mock-when>
```

You can set the **processor** attribute to define the processor to mock and set the
**with-attribute** element to define the attribute name and value. In the previous example, you
define a POST method.

You can also use DataWeave functions and mappings to set the `value` attribute in the
**then-return** element. For example, create a **mockPost.dwl** in the
**src/test/resources/sample\_data** file:

```none
%dw 2.0
output application/json
---
{
	"foo" : "var"
}
```

This DataWeave file creates the payload to send in a POST request. You can then use the **readUrl**
DataWeave function to read the mapping file:

```xml
<munit-tools:then-return>
  <munit-tools:payload value="#[readUrl('classpath://sample_data/mockPost.dwl')]" mediaType="application/json" encoding="UTF-8" />
</munit-tools:then-return>
```

Finally, you can configure a **then-return** element to define the type of response the mocked
processor returns. It can be a payload, a variable, a list of attributes, or an error.

You can use either a **then-return** to return a static, constant value, or you can use a
**then-call** to invoke a flow for cases where the returned value can change over time, or to have
different responses according to certain inputs.

> [!NOTE] The mocking of the processors is executed after the initialization of the Mule app, and
> some connectors can require credentials or configurations to start the app, even when its
> processors are mocked.

> [!NOTE] Logger processor and Transform Message processor (DataWeave) cannot be mocked.

## Mock Using Then-Return

For example, you can mock a web service consumer such as this one:

```xml
<wsc:config name="Web_Service_Consumer_Config">
  <wsc:connection wsdlLocation="tshirt.wsdl" service="TshirtService" port="TshirtServicePort" address="http://tshirt-service.cloudhub.io"/>
</wsc:config>

<wsc:consume config-ref="Web_Service_Consumer_Config" operation="OrderTshirt"/>
```

By configuring the **mock-when** processor as shown in the following example:

```xml
<munit-tools:mock-when processor="wsc:consume">
    <munit-tools:with-attributes>
        <munit-tools:with-attribute attributeName="operation" whereValue="#['OrderTshirt']"/>
    </munit-tools:with-attributes>
</munit-tools:mock-when>
```

This **mock-when** processor mocks a call to the **OrderTshirt** operation in the WSDL definition.

You can also mock specific variables:

```xml
<munit-tools:mock-when processor="http:request">
	<munit-tools:with-attributes>
	    <munit-tools:with-attribute attributeName="config-ref" whereValue="#['HTTP_Request_configuration']"/>
	</munit-tools:with-attributes>
	<munit-tools:then-return>
	  <munit-tools:variables>
	  	<munit-tools:variable key="aVariable" value="#['aValue']"/>
	  </munit-tools:variables>
	</munit-tools:then-return>
</munit-tools:mock-when>
```

### Mock Errors

The **Mock When** processor also enables you to mock errors in your operations. Assume that you have
an HTTP requester in your flow with an On-Error scope that catches any connectivity errors and
returns a custom payload if the connection fails:

```xml
<http:request-config name="HTTP_Request_Config">
    <http:request-connection host="localhost" port="8888"/>
</http:request-config>

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

<flow name="api-request">
    <http:listener config-ref="HTTP_Listener_Config" path="/"/>
    <http:request method="GET" config-ref="HTTP_Request_Config" path="/api"/>
    <error-handler>
        <on-error-continue enableNotifications="true" logException="true" type="HTTP:CONNECTIVITY">
            <set-payload value="#['Connection Error']"/>
        </on-error-continue>
    </error-handler>
</flow>
```

You can assert that every time the HTTP request fails, your application returns your custom payload:

```xml
<munit:test name="HTTP-fail-test" description="Asserts Custom Payload in HTTP Connectivity errors.">
    <munit:behavior>
        <munit-tools:mock-when processor="http:request">
            <munit-tools:with-attributes>
                <munit-tools:with-attribute attributeName="config-ref"
                                            whereValue="#['HTTP_Request_Config']"/> (1)
            </munit-tools:with-attributes>

            <munit-tools:then-return>
                <munit-tools:error typeId="#['HTTP:CONNECTIVITY']"/> (2)
            </munit-tools:then-return>
        </munit-tools:mock-when>
    </munit:behavior>

    <munit:execution>
        <flow-ref name="api-request"/> (3)
    </munit:execution>

    <munit:validation>
      <munit-tools:assert-that expression="#[payload]" is="#[MunitTools::equalToIgnoringCase('connection error')]"/> (4)
    </munit:validation>
</munit:test>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Mock an HTTP Requester with the configuration of the requester in your flow.</td></tr><tr><td><i data-value="2"></i><b>2</b></td><td>Configure a then-return element to throw an <strong>HTTP:CONNECTIVITY</strong> error.<br>This triggers the On-error scope in your application.</td></tr><tr><td><i data-value="3"></i><b>3</b></td><td>Execute the flow containing the requester.</td></tr><tr><td><i data-value="4"></i><b>4</b></td><td>Assert that the returned payload is the one you set in the On-error scope.</td></tr></tbody></table>

You cannot return all known error types of a Mule application. You can return the type of errors
defined in the modules the current flow uses. If you try to return an error type that is out of the
scope of the flow you’re testing, you get a **MULE:UNKNOWN** error instead of the configured one.

### Parameters

If you create a mock error, choose one of the following parameters to provide the trigger for the
error in the **Then-return** tab:

- **TypeId**: Follows a Mule Error type definition. For example, the HTTP:CONNECTIVITY error
  explained before.

- **Cause**: Expects the instance of the exception with a message for the error. For example, using
  Java, write the expression:

```java
#[java!java::lang::Exception::new("Exception Message")]
```

## Mock Using Then-Call

To dynamically mock a variable, use **then-call** as follows:

```xml
<flow name="flow-to-be-mocked">
    <set-variable variableName="count" value="#[0]"/>
</flow>

<flow name="flow-to-test">
    <flow-ref name="flow-to-be-mocked"/> (1)
</flow>

<flow name="count-to-3"> (2)
    <choice>
        <when expression="#[vars.count == null]">
            <set-variable variableName="count" value="#[1]" doc:name="Create counter"/>
        </when>

        <when expression="#[vars.count &lt; 3]">
            <set-variable variableName="count" value="#[vars.count + 1]"
                          doc:name="Increase count by 1, up to 3"/>
        </when>
    </choice>
</flow>

<munit:test name="variable-mock-test">
    <munit:behavior>
        <munit-tools:mock-when processor="mule:flow-ref">
            <munit-tools:with-attributes>
                <munit-tools:with-attribute attributeName="name" whereValue="#['flow-to-be-mocked']"/>
            </munit-tools:with-attributes>

            <munit-tools:then-call flow="count-to-3"/> (3)
        </munit-tools:mock-when>
    </munit:behavior>

    <munit:execution>
        <flow-ref name="flow-to-test"/> <!-- 1 -->
        <flow-ref name="flow-to-test"/> <!-- 2 -->
        <flow-ref name="flow-to-test"/> <!-- 3 -->
        <flow-ref name="flow-to-test"/> <!-- 3 -->
    </munit:execution>

    <munit:validation>
        <munit-tools:assert-that expression="#[vars.count]" is="#[MunitTools::equalTo(3)]"/>
    </munit:validation>
</munit:test>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>This is the processor you mock.</td></tr><tr><td><i data-value="2"></i><b>2</b></td><td>The mock calls this flow. The mock sets a variable that changes depending on the incoming event.</td></tr><tr><td><i data-value="3"></i><b>3</b></td><td>Configure the mock to call the desired flow.</td></tr></tbody></table>

## See Also

- [Assert That Event Processor](https://docs.mulesoft.com/munit/2.3/assertion-event-processor)

- [Fail Event Processor](https://docs.mulesoft.com/munit/2.3/fail-event-processor)

- [Run Custom Event Processor](https://docs.mulesoft.com/munit/2.3/run-custom-event-processor)

- [Set Event Processor](https://docs.mulesoft.com/munit/2.3/set-event-processor)

- [Verify Event Processor](https://docs.mulesoft.com/munit/2.3/verify-event-processor)

<!-- document id=d5d4a8b043095933ef7659e94f12d43e2a30d392c5655a3ea7702272b89964e1 url=/mulesoft/current/en-us/munit/3.6/mock-event-processor.md -->

---
product: MUnit
version: 3.6
keywords: munit, testing, unit testing
---

# Mock When Event Processor

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The **Mock When** processor enables you to mock an event processor when it matches the defined name
and attributes.

For example, you can use the **Mock Event** processor to mock a POST request with a mocked payload:

```xml
<munit-tools:mock-when processor="http:request">
   <munit-tools:with-attributes>
       <munit-tools:with-attribute attributeName="method" whereValue="#['POST']"/>
   </munit-tools:with-attributes>
   <munit-tools:then-return>
       <munit-tools:payload value="#['mockPayload']"/>
   </munit-tools:then-return>
</munit-tools:mock-when>
```

You can set the **processor** attribute to define the processor to mock and set the
**with-attribute** element to define the attribute name and value. In the previous example, you
define a POST method.

You can also use DataWeave functions and mappings to set the `value` attribute in the
**then-return** element. For example, create a **mockPost.dwl** in the
**src/test/resources/sample\_data** file:

```none
%dw 2.0
output application/json
---
{
	"foo" : "var"
}
```

This DataWeave file creates the payload to send in a POST request. You can then use the **readUrl**
DataWeave function to read the mapping file:

```xml
<munit-tools:then-return>
  <munit-tools:payload value="#[readUrl('classpath://sample_data/mockPost.dwl')]" mediaType="application/json" encoding="UTF-8" />
</munit-tools:then-return>
```

Finally, you can configure a **then-return** element to define the type of response the mocked
processor returns. It can be a payload, a variable, a list of attributes, or an error.

You can use either a **then-return** to return a static, constant value, or you can use a
**then-call** to invoke a flow for cases where the returned value can change over time, or to have
different responses according to certain inputs.

> [!NOTE] The mocking of the processors is executed after the initialization of the Mule app, and
> some connectors can require credentials or configurations to start the app, even when its
> processors are mocked.

> [!NOTE] Logger processor and Transform Message processor (DataWeave) cannot be mocked.

## Mock Using Then-Return

For example, you can mock a web service consumer such as this one:

```xml
<wsc:config name="Web_Service_Consumer_Config">
  <wsc:connection wsdlLocation="tshirt.wsdl" service="TshirtService" port="TshirtServicePort" address="http://tshirt-service.cloudhub.io"/>
</wsc:config>

<wsc:consume config-ref="Web_Service_Consumer_Config" operation="OrderTshirt"/>
```

By configuring the **mock-when** processor as shown in the following example:

```xml
<munit-tools:mock-when processor="wsc:consume">
    <munit-tools:with-attributes>
        <munit-tools:with-attribute attributeName="operation" whereValue="#['OrderTshirt']"/>
    </munit-tools:with-attributes>
</munit-tools:mock-when>
```

This **mock-when** processor mocks a call to the **OrderTshirt** operation in the WSDL definition.

You can also mock specific variables:

```xml
<munit-tools:mock-when processor="http:request">
	<munit-tools:with-attributes>
	    <munit-tools:with-attribute attributeName="config-ref" whereValue="#['HTTP_Request_configuration']"/>
	</munit-tools:with-attributes>
	<munit-tools:then-return>
	  <munit-tools:variables>
	  	<munit-tools:variable key="aVariable" value="#['aValue']"/>
	  </munit-tools:variables>
	</munit-tools:then-return>
</munit-tools:mock-when>
```

### Mock Errors

The **Mock When** processor also enables you to mock errors in your operations. Assume that you have
an HTTP requester in your flow with an On-Error scope that catches any connectivity errors and
returns a custom payload if the connection fails:

```xml
<http:request-config name="HTTP_Request_Config">
    <http:request-connection host="localhost" port="8888"/>
</http:request-config>

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

<flow name="api-request">
    <http:listener config-ref="HTTP_Listener_Config" path="/"/>
    <http:request method="GET" config-ref="HTTP_Request_Config" path="/api"/>
    <error-handler>
        <on-error-continue enableNotifications="true" logException="true" type="HTTP:CONNECTIVITY">
            <set-payload value="#['Connection Error']"/>
        </on-error-continue>
    </error-handler>
</flow>
```

You can assert that every time the HTTP request fails, your application returns your custom payload:

```xml
<munit:test name="HTTP-fail-test" description="Asserts Custom Payload in HTTP Connectivity errors.">
    <munit:behavior>
        <munit-tools:mock-when processor="http:request">
            <munit-tools:with-attributes>
                <munit-tools:with-attribute attributeName="config-ref"
                                            whereValue="#['HTTP_Request_Config']"/> (1)
            </munit-tools:with-attributes>

            <munit-tools:then-return>
                <munit-tools:error typeId="#['HTTP:CONNECTIVITY']"/> (2)
            </munit-tools:then-return>
        </munit-tools:mock-when>
    </munit:behavior>

    <munit:execution>
        <flow-ref name="api-request"/> (3)
    </munit:execution>

    <munit:validation>
      <munit-tools:assert-that expression="#[payload]" is="#[MunitTools::equalToIgnoringCase('connection error')]"/> (4)
    </munit:validation>
</munit:test>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Mock an HTTP Requester with the configuration of the requester in your flow.</td></tr><tr><td><i data-value="2"></i><b>2</b></td><td>Configure a then-return element to throw an <strong>HTTP:CONNECTIVITY</strong> error.<br>This triggers the On-error scope in your application.</td></tr><tr><td><i data-value="3"></i><b>3</b></td><td>Execute the flow containing the requester.</td></tr><tr><td><i data-value="4"></i><b>4</b></td><td>Assert that the returned payload is the one you set in the On-error scope.</td></tr></tbody></table>

You cannot return all known error types of a Mule application. You can return the type of errors
defined in the modules the current flow uses. If you try to return an error type that is out of the
scope of the flow you’re testing, you get a **MULE:UNKNOWN** error instead of the configured one.

### Parameters

If you create a mock error, choose one of the following parameters to provide the trigger for the
error in the **Then-return** tab:

- **TypeId**: Follows a Mule Error type definition. For example, the HTTP:CONNECTIVITY error
  explained before.

- **Cause**: Expects the instance of the exception with a message for the error. For example, using
  Java, write the expression:

```java
#[java!java::lang::Exception::new("Exception Message")]
```

## Mock Using Then-Call

To dynamically mock a variable, use **then-call** as follows:

```xml
<flow name="flow-to-be-mocked">
    <set-variable variableName="count" value="#[0]"/>
</flow>

<flow name="flow-to-test">
    <flow-ref name="flow-to-be-mocked"/> (1)
</flow>

<flow name="count-to-3"> (2)
    <choice>
        <when expression="#[vars.count == null]">
            <set-variable variableName="count" value="#[1]" doc:name="Create counter"/>
        </when>

        <when expression="#[vars.count &lt; 3]">
            <set-variable variableName="count" value="#[vars.count + 1]"
                          doc:name="Increase count by 1, up to 3"/>
        </when>
    </choice>
</flow>

<munit:test name="variable-mock-test">
    <munit:behavior>
        <munit-tools:mock-when processor="mule:flow-ref">
            <munit-tools:with-attributes>
                <munit-tools:with-attribute attributeName="name" whereValue="#['flow-to-be-mocked']"/>
            </munit-tools:with-attributes>

            <munit-tools:then-call flow="count-to-3"/> (3)
        </munit-tools:mock-when>
    </munit:behavior>

    <munit:execution>
        <flow-ref name="flow-to-test"/> <!-- 1 -->
        <flow-ref name="flow-to-test"/> <!-- 2 -->
        <flow-ref name="flow-to-test"/> <!-- 3 -->
        <flow-ref name="flow-to-test"/> <!-- 3 -->
    </munit:execution>

    <munit:validation>
        <munit-tools:assert-that expression="#[vars.count]" is="#[MunitTools::equalTo(3)]"/>
    </munit:validation>
</munit:test>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>This is the processor you mock.</td></tr><tr><td><i data-value="2"></i><b>2</b></td><td>The mock calls this flow. The mock sets a variable that changes depending on the incoming event.</td></tr><tr><td><i data-value="3"></i><b>3</b></td><td>Configure the mock to call the desired flow.</td></tr></tbody></table>

## See Also

- [Assert That Event Processor](https://docs.mulesoft.com/munit/3.6/assertion-event-processor)

- [Fail Event Processor](https://docs.mulesoft.com/munit/3.6/fail-event-processor)

- [Run Custom Event Processor](https://docs.mulesoft.com/munit/3.6/run-custom-event-processor)

- [Set Event Processor](https://docs.mulesoft.com/munit/3.6/set-event-processor)

- [Verify Event Processor](https://docs.mulesoft.com/munit/3.6/verify-event-processor)

<!-- document id=0892e89e6df7e9e52e824892a7feb7027315e31166a9e9934c159896d49ca957 url=/mulesoft/current/en-us/munit/2.3/mock-before-after-foreach-cookbook.md -->

---
product: MUnit
version: 2.3
---

# Mocking a Message Before and Inside a Foreach Processor

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

Suppose you have a processor inside a `foreach` scope and you want to provide different values on
each iteration:

```xml
<flow name="foreachFlow">
	<foreach doc:name="For Each">
		<flow-ref doc:name="Flow Reference" name="FlowToMock"/>
	</foreach>
</flow>
```

Use an `munit-tools:mock-when` processor to mock the processor in your flow and use the `then-call`
operation to call a new flow that set payloads depending on the `foreach` status:

```xml
<munit-tools:mock-when doc:name="Mock when" processor="flow-ref">
	<munit-tools:with-attributes >
		<munit-tools:with-attribute attributeName="name" whereValue="FlowToMock" />
	</munit-tools:with-attributes>
	<munit-tools:then-call flow="MockedFlow" />
</munit-tools:mock-when>
```

Inside the flow that is called by the `then-call` you can use a `Choice` processor to evaluate a
value and set a mocked payload. In this case, the `foreach` counter is evaluated to decide which
payload to set:

```xml
<flow name="MockedFlow" >
	<choice doc:name="Choice">
		<when expression="#[vars.counter == 1]">
			<set-payload value='#["MOCKED1"]' doc:name="Set Payload" />
		</when>
		<when expression="#[vars.counter == 2]">
			<set-payload value='#["MOCKED2"]' doc:name="Set Payload" />
		</when>
		<otherwise >
			<set-payload value='#["DEFAULT"]' doc:name="Set Payload" />
		</otherwise>
	</choice>
</flow>
```

## Mock a Mule Message

To mock processors like `file:list` or `ftp:list`, you must return a Mule message collection as
payload. `MunitTools` provides a function to mock these payloads:

```none
fun createMessage(payload: Any, attributes: Any = null)

fun createMessage(payload: Any, mimeType: String|Null , attributes: Any, attributeMimeType: String|Null)
```

```xml
<flow doc:name="Flow" >
	<file:list doc:name="List" config-ref="File_Config" directoryPath="/tmp/"/>
</flow>

<munit-tools:mock-when processor="file:list">
   <munit-tools:with-attributes>
       <munit-tools:with-attribute attributeName="doc:name" whereValue="List"/>
   </munit-tools:with-attributes>
   <munit-tools:then-return>
       <munit-tools:payload value="#[[MunitTools::createMessage( &quot;ITEM-1&quot;,  &quot;text/plain&quot;, { property : 'ATTRIBUTE-1'}, null) , MunitTools::createMessage( &quot;ITEM-2&quot;,  &quot;text/plain&quot;, { property : 'ATTRIBUTE-2'}, null)]]" />
   </munit-tools:then-return>
</munit-tools:mock-when>
```

## See Also

- [Mock When Event Processor](https://docs.mulesoft.com/munit/2.3/mock-event-processor)

<!-- document id=5b01ff293e8217567d6b72333fae2586145979f47d131f172a5e4b3c392ad4af url=/mulesoft/current/en-us/munit/3.6/mock-before-after-foreach-cookbook.md -->

---
product: MUnit
version: 3.6
---

# Mocking a Message Before and Inside a Foreach Processor

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

Suppose you have a processor inside a `foreach` scope and you want to provide different values on
each iteration:

```xml
<flow name="foreachFlow">
	<foreach doc:name="For Each">
		<flow-ref doc:name="Flow Reference" name="FlowToMock"/>
	</foreach>
</flow>
```

Use an `munit-tools:mock-when` processor to mock the processor in your flow and use the `then-call`
operation to call a new flow that set payloads depending on the `foreach` status:

```xml
<munit-tools:mock-when doc:name="Mock when" processor="flow-ref">
	<munit-tools:with-attributes >
		<munit-tools:with-attribute attributeName="name" whereValue="FlowToMock" />
	</munit-tools:with-attributes>
	<munit-tools:then-call flow="MockedFlow" />
</munit-tools:mock-when>
```

Inside the flow that is called by the `then-call` you can use a `Choice` processor to evaluate a
value and set a mocked payload. In this case, the `foreach` counter is evaluated to decide which
payload to set:

```xml
<flow name="MockedFlow" >
	<choice doc:name="Choice">
		<when expression="#[vars.counter == 1]">
			<set-payload value='#["MOCKED1"]' doc:name="Set Payload" />
		</when>
		<when expression="#[vars.counter == 2]">
			<set-payload value='#["MOCKED2"]' doc:name="Set Payload" />
		</when>
		<otherwise >
			<set-payload value='#["DEFAULT"]' doc:name="Set Payload" />
		</otherwise>
	</choice>
</flow>
```

## Mock a Mule Message

To mock processors like `file:list` or `ftp:list`, you must return a Mule message collection as
payload. `MunitTools` provides a function to mock these payloads:

```none
fun createMessage(payload: Any, attributes: Any = null)

fun createMessage(payload: Any, mimeType: String|Null , attributes: Any, attributeMimeType: String|Null)
```

```xml
<flow doc:name="Flow" >
	<file:list doc:name="List" config-ref="File_Config" directoryPath="/tmp/"/>
</flow>

<munit-tools:mock-when processor="file:list">
   <munit-tools:with-attributes>
       <munit-tools:with-attribute attributeName="doc:name" whereValue="List"/>
   </munit-tools:with-attributes>
   <munit-tools:then-return>
       <munit-tools:payload value="#[[MunitTools::createMessage( &quot;ITEM-1&quot;,  &quot;text/plain&quot;, { property : 'ATTRIBUTE-1'}, null) , MunitTools::createMessage( &quot;ITEM-2&quot;,  &quot;text/plain&quot;, { property : 'ATTRIBUTE-2'}, null)]]" />
   </munit-tools:then-return>
</munit-tools:mock-when>
```

## See Also

- [Mock When Event Processor](https://docs.mulesoft.com/munit/3.6/mock-event-processor)

<!-- document id=532d29fee0e63dfcb72946be7ba128d69dfad4185d8a6dec48e8dbe3f4220c2f url=/mulesoft/current/en-us/munit/2.3/mock-file-cookbook.md -->

---
product: MUnit
version: 2.3
---

# Mocking Resources for Your Tests

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

As your tests suites start to get bigger and more complex, it’s a good practice to externalize some
parts of the test code, not only so that you can keep the code clean and organized but also to reuse
the files that you need to mock for your tests.

You can leverage DataWeave to mock your test code, either by creating DataWeave scripts or by using
variables in a DataWeave module.

## Mock Files Using DataWeave File

You can write a DataWeave file that returns the data that you want to mock, save the file under a
folder in `src/test/resources` and then use a DataWeave function from your test to read this file.

For example, imagine that you have defined a `mockPost.dwl` file in the
`src/test/resources/sample_data` folder with the following content:

```none
%dw 2.0
output application/json
---
{
	"foo" : "var"
}
```

This DataWeave file (`mockPost.dwl`) is a sample that creates a mock payload that you want to return
in an `http:request` request.

When configuring the `then-return` section in the `mock-when`, use the `readUrl` function to read
the mapping file:

```xml
<munit-tools:then-return>
  <munit-tools:payload value="#[readUrl('classpath://sample_data/mockPost.dwl')]" mediaType="application/json" encoding="UTF-8" />
</munit-tools:then-return>
```

The `classpath-based` URL uses the `classpath:` protocol prefix to find the file defined in
`src/test/resources`.

## Mock Files Using Variables in a DataWeave Module

You can create a DataWeave module to centralize all your mocked data in a single file by declaring
it using DataWeave variables.

For example, imagine that you create a custom DataWeave module by creating a `TestData.dwl` file in
`src/test/resources`, and you add variables with references to different mocked data, either from
files or inline:

```none
import getResourceAsString from MunitTools

var mockPost = readUrl('classpath://sample_data/mockPost.dwl')
var foo = "N123"
var jsonFromFile = read(getResourceAsString('sample_data/mydata.json'), 'application/json')
var jsonObject = { paymentID: "1B56925769601335TLQMIWVY" }
```

You can then access any of the defined variables in the DataWeave module by importing the variables
from your module:

```xml
<munit-tools:then-return >
    <munit-tools:variables>
        <munit-tools:variable key="ticket" value="#[import TestData output application/json --- TestData::mockPost]" mediaType="application/json" />
    </munit-tools:variables>
</munit-tools:then-return>
```

## See Also

- [Create Custom Modules and Mappings](https://docs.mulesoft.com/dataweave/latest/dataweave-create-module)

<!-- document id=f62b9a65fb287673093cfaa1eebd2287e2012b90622277ad9868ecf77519601a url=/mulesoft/current/en-us/munit/3.6/mock-file-cookbook.md -->

---
product: MUnit
version: 3.6
---

# Mocking Resources for Your Tests

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

As your tests suites start to get bigger and more complex, it’s a good practice to externalize some
parts of the test code, not only so that you can keep the code clean and organized but also to reuse
the files that you need to mock for your tests.

You can leverage DataWeave to mock your test code, either by creating DataWeave scripts or by using
variables in a DataWeave module.

## Mock Files Using DataWeave File

You can write a DataWeave file that returns the data that you want to mock, save the file under a
folder in `src/test/resources` and then use a DataWeave function from your test to read this file.

For example, imagine that you have defined a `mockPost.dwl` file in the
`src/test/resources/sample_data` folder with the following content:

```none
%dw 2.0
output application/json
---
{
	"foo" : "var"
}
```

This DataWeave file (`mockPost.dwl`) is a sample that creates a mock payload that you want to return
in an `http:request` request.

When configuring the `then-return` section in the `mock-when`, use the `readUrl` function to read
the mapping file:

```xml
<munit-tools:then-return>
  <munit-tools:payload value="#[readUrl('classpath://sample_data/mockPost.dwl')]" mediaType="application/json" encoding="UTF-8" />
</munit-tools:then-return>
```

The `classpath-based` URL uses the `classpath:` protocol prefix to find the file defined in
`src/test/resources`.

## Mock Files Using Variables in a DataWeave Module

You can create a DataWeave module to centralize all your mocked data in a single file by declaring
it using DataWeave variables.

For example, imagine that you create a custom DataWeave module by creating a `TestData.dwl` file in
`src/test/resources`, and you add variables with references to different mocked data, either from
files or inline:

```none
import getResourceAsString from MunitTools

var mockPost = readUrl('classpath://sample_data/mockPost.dwl')
var foo = "N123"
var jsonFromFile = read(getResourceAsString('sample_data/mydata.json'), 'application/json')
var jsonObject = { paymentID: "1B56925769601335TLQMIWVY" }
```

You can then access any of the defined variables in the DataWeave module by importing the variables
from your module:

```xml
<munit-tools:then-return >
    <munit-tools:variables>
        <munit-tools:variable key="ticket" value="#[import TestData output application/json --- TestData::mockPost]" mediaType="application/json" />
    </munit-tools:variables>
</munit-tools:then-return>
```

## See Also

- [Create Custom Modules and Mappings](https://docs.mulesoft.com/dataweave/latest/dataweave-create-module)

<!-- document id=8db49f4e5e82abb57eb404f486bfa23b0e1f04e4fb4b9c8031f4fa29f78d272a url=/mulesoft/current/en-us/munit/latest/assertion-equals-processor.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit Assert Equals Processor

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The MUnit Assert Equals processor validates that two values are equal during a MUnit test. Use it to
check the state of a Mule Event’s payload or variables after production code runs.

For example, to assert that a payload is equal to a certain value, you can configure the
Assert-Equals processor the following way:

```xml
<munit-tools:assert-equals
  actual="#[payload]"
  expected="#[2]"
  message="The payload should be 2"/>
```

If the `expected` attribute is a String, you can specify the literal value without requiring an
expression.

```xml
<munit-tools:assert-equals
  actual="#[payload]"
  expected="Example"
  message="The payload should be 'Example'"/>
```

If this assertion fails, the processor throws a `MUNIT-TOOLS:ASSERTION_ERROR`.

<!-- document id=00a0f78b44a29548c293983265d833f5c0901ed6e6c7d952fa525598d15b7976 url=/mulesoft/current/en-us/munit/latest/assertion-expression-processor.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit Assert Expression Processor

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The MUnit Assert Expression processor evaluates DataWeave expressions to validate a Mule event’s
content during a MUnit test, using the DataWeave Assertions Library. Use it when you need
DataWeave-native assertions or want to create custom matchers with the DataWeave Assertions Library.

For example, to assert that a payload is equal to a certain value, you can configure the
Assert-Expression processor using the equalTo() matcher.

```xml
<munit-tools:assert>
    <munit-tools:that>#[ import * from dw::test::Asserts ---
        payload must equalTo('example') ]
    </munit-tools:that>
</munit-tools:assert>
```

## Perform Complex Assertions

The DW assertions library allows you to assert the state of the Mule Event’s content in a deeper
way.

```xml
<munit-tools:assert>
    <munit-tools:that>#[ import * from dw::test::Asserts ---
        vars.attributes must [beObject(), $.statusCode must equalTo(200), $.method must equalTo('GET')] ]
    </munit-tools:that>
</munit-tools:assert>
```

## Create Your Own Matcher

To create your own matcher, you can add DW files to your `src/test/resources` folder. For example, a
file called `MyMatcher.dwl` with the following content:

```dataweave
import * from dw::test::Asserts

fun beEven(): Matcher<Number> =
     (actual:Number) -> do {
         var matchesEven = (actual mod 2) == 0
         ---
         {
             matches: matchesEven,
             description: {expected: " to be an even number.", actual: write(actual) as String}
         }
     }
```

And then use it in your Assert-Expression processor:

```xml
<munit-tools:assert>
    <munit-tools:that>#[ import * from dw::test::Asserts ---
        payload must MyMatcher::beEven() ]
    </munit-tools:that>
</munit-tools:assert>
```

If this assertion fails, the processor throws a `MUNIT-TOOLS:ASSERTION_ERROR`.

> [!WARNING] Matchers from the `dw::test::Asserts` library are not compatible with the `MunitTools`
> matchers. You can’t use `dw::test::Asserts` with the Assert-That processor, and you can’t use
> `MunitTools` matchers with the Assert-Expression processor.

<!-- document id=114dd7ea33e9f6ea30f4a9b6f35171035755d4f4de20ff908be44558ad927eef url=/mulesoft/current/en-us/munit/latest/assertion-event-processor.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
keywords: mule, esb, tests, qa, quality assurance, verify, functional testing, unit testing, stress testing
---

# MUnit Assert That Event Processor

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The MUnit Assert That event processor validates the state of a Mule event’s content during a MUnit
test using DataWeave MUnit matchers. Use it to assert conditions on any value in an expression after
production code runs.

The Assert That processor uses a set of DataWeave functions called `MUnit matchers` to define the
assertion conditions for any value in an expression.

For example, to assert that a payload is equal to a certain value, configure the Assert That
processor using the `equalTo()` matcher.

```xml
<munit-tools:assert-that
  expression="#[payload]"
  is="#[MunitTools::equalTo('example')]"
  message="The payload should be ‘example’"/>
```

Or you can also check if the payload is null using the `nullValue()` matcher.

```xml
<munit-tools:assert-that
  expression="#[payload]"
  is="#[MunitTools::nullValue()]"
  message="The payload should be null"/>
```

See [MUnit Matchers](https://docs.mulesoft.com/munit/latest/munit-matchers) for more information.

If these assertion fails, the processor throws a `MUNIT-TOOLS:ASSERTION_ERROR`.

## See Also

- [MUnit Matchers](https://docs.mulesoft.com/munit/latest/munit-matchers)

<!-- document id=648ae9153d6a836bdd0195fb2df2d7933af17a67cbd0d69c7cc987df3ec32c34 url=/mulesoft/current/en-us/munit/latest/before-after-scopes-reference.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit Before and After Scopes

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

MUnit Before and After scopes let you run setup and teardown code at the suite or test level in a
MUnit test suite. Use Before scopes to prepare shared state and After scopes to clean it up, so each
test starts and ends in a controlled state.

## Before Suite Scope

The MUnit Before Suite scope runs once before all tests in the suite.

For example, suppose you have an MUnit Test Suite file with four tests. The code inside an MUnit
Before Suite runs just once, before your four tests.

> [!NOTE] You can only use one Before Suite scope per MUnit test suite.

Use a Before Suite scope to set up state that every test in the suite shares, such as seeding an
in-memory database, starting a server utility, or storing values that the tests read. In the
example, the `jobtitlelookup.csv` file creates the table and its initial contents when the database
server starts, and the Before Suite adds one shared row that all tests in the suite query:

Before Suite example

```xml
<dbserver:config name="MUnit_DB_Server_Config">
  <dbserver:connection csv="jobtitlelookup.csv" database="DATABASE_NAME"
    connectionStringParameters="MODE=MySQL" />
</dbserver:config>

<munit:before-suite name="before-suite" description="Adds a shared row for the whole suite">
  <dbserver:execute config-ref="MUnit_DB_Server_Config"
    sql="INSERT INTO jobtitlelookup VALUES ('Support Engineer','10','SUP');" />
</munit:before-suite>

<munit:test name="munit.test" description="Test">
  <!-- Every test in this suite can query the row added by the before-suite -->
</munit:test>
```

> [!NOTE] The `before-suite` scope is located outside the MUnit test, so the insert runs once before
> the first test instead of once per test.

When you place a before-suite in the Anypoint Studio canvas, the scope locates outside the MUnit
test.

## After Suite Scope

The MUnit After Suite scope runs once after all tests in the suite complete.

For instance, let’s suppose you have an MUnit Test Suite File with four tests. The code inside an
MUnit After Suite, runs just once, after all your tests.

> [!NOTE] You can only use one After Suite scope per MUnit test suite.

Use an After Suite scope to tear down whatever the Before Suite created, so the next suite run
starts from a clean state. The example removes only the row that the Before Suite added, leaving the
contents loaded from the CSV file untouched:

After Suite example

```xml
<munit:before-suite name="before.suite" description="Adds a shared row for the whole suite">
  <dbserver:execute config-ref="MUnit_DB_Server_Config"
    sql="INSERT INTO jobtitlelookup VALUES ('Support Engineer','10','SUP');" />
</munit:before-suite>

<munit:test name="munit.test" description="Test">
  <!-- some more mule code here -->
</munit:test>

<munit:after-suite name="after.suite" description="Removes the data created for the suite">
  <dbserver:execute config-ref="MUnit_DB_Server_Config"
    sql="DELETE FROM jobtitlelookup WHERE JOBTITLEID='SUP';" />
</munit:after-suite>
```

> [!NOTE] The `after-suite` scope is located outside the MUnit test, so the cleanup runs once after
> the last test completes.

When you place an after-suite in the Anypoint Studio canvas, the scope locates outside the MUnit
test.

## Before Test Scope

The MUnit Before Test scope runs before each individual test in the suite.

For instance, let’s suppose you have an MUnit Test Suite file with four tests. The code inside an
MUnit Before test runs before each of your four tests; it runs four times.

> [!NOTE] You can only use one Before Test scope per MUnit test suite.

Use a Before Test scope to set up state that each test needs individually, such as inserting a
record, creating a file, or setting a variable that the test consumes. The following example inserts
a record and sets the variable that the flow under test reads:

Before Test example

```xml
<munit:before-test name="before.test" description="Creates the record each test needs">
  <dbserver:execute config-ref="MUnit_DB_Server_Config"
    sql="INSERT INTO jobtitlelookup VALUES ('Culinary Team Member','10','HIR');" />
  <set-variable variableName="jobid" value="HIR" />
</munit:before-test>

<munit:test name="munit.test" description="Test">
  <munit:execution>
    <flow-ref name="selectFlow" />
  </munit:execution>
  <munit:validation>
    <munit-tools:assert-equals actual="#[vars.job]" expected="Culinary Team Member" />
  </munit:validation>
</munit:test>
```

> [!NOTE] The `before.test` scope is located outside the MUnit test, so each test starts from the
> same record and variable value without repeating the setup in every test.

When you place a before-test in the Anypoint Studio canvas, the scope locates outside the MUnit
test.

## After Test Scope

The MUnit After Test scope runs after each individual test in the suite completes.

For instance, let’s suppose you have an MUnit Test Suite file with four tests. The code inside an
MUnit After Test runs after each of your four tests; it runs four times.

> [!NOTE] You can only use one After Test scope per MUnit test suite.

Use an After Test scope to undo what the Before Test created, so one test doesn’t leave data behind
that affects the next one. The following example deletes the record that the Before Test inserted:

After Test example

```xml
<munit:before-test name="before.test" description="Creates the record each test needs">
  <dbserver:execute config-ref="MUnit_DB_Server_Config"
    sql="INSERT INTO jobtitlelookup VALUES ('Culinary Team Member','10','HIR');" />
</munit:before-test>

<munit:test name="munit.test" description="Test">
  <!-- some more mule code here -->
</munit:test>

<munit:after-test name="after.test" description="Removes the record created for the test">
  <dbserver:execute config-ref="MUnit_DB_Server_Config"
    sql="DELETE FROM jobtitlelookup WHERE JOBTITLEID='HIR';" />
</munit:after-test>
```

> [!NOTE] The `after.test` scope is located outside the MUnit test, so the cleanup runs after each
> test rather than once after the suite.

When you place an after-test in the Anypoint Studio canvas, the scope locates outside the MUnit
test.

## Before Suite Reference

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>name</code></p></td><td><p>Defines the name of the Before suite. The name must be unique inside the suite.</p></td></tr><tr><td><p><code>description</code></p></td><td><p>Describes the actions performed.</p></td></tr></tbody></table>

## After Suite Reference

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>name</code></p></td><td><p>Defines the name of the After suite. The name must be unique inside the suite.</p></td></tr><tr><td><p><code>description</code></p></td><td><p>Describes the actions performed.</p></td></tr></tbody></table>

## Before Test Reference

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>name</code></p></td><td><p>Defines the name of the Before test. The name must be unique inside the suite.</p></td></tr><tr><td><p><code>description</code></p></td><td><p>Describes the actions performed.</p></td></tr></tbody></table>

## After Test Reference

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>name</code></p></td><td><p>Defines the name of the After test. The name must be unique inside the suite.</p></td></tr><tr><td><p><code>description</code></p></td><td><p>Describes the actions performed.</p></td></tr></tbody></table>

## See Also

- [MUnit Test Structure Fundamentals](https://docs.mulesoft.com/munit/latest/munit-test-concept)

- [Install the MUnit Database Server Module](https://docs.mulesoft.com/munit/latest/db-util)

- [Configure the MUnit Database Server Utility](https://docs.mulesoft.com/munit/latest/db-server-cookbook)

- [Install the MUnit FTP Server Module](https://docs.mulesoft.com/munit/latest/ftp-util)

- [Enable Flow Sources in MUnit](https://docs.mulesoft.com/munit/latest/enable-flow-sources-concept)

<!-- document id=cf2739636fafbfbb365eb40f05c4ac118b9c907c45bd218dff43d3037739aa3a url=/mulesoft/current/en-us/munit/latest/comparable-matchers-reference.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit Comparable Matchers Reference

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

MUnit Comparable matchers are matcher functions that assert comparison conditions on values during a
MUnit test. Use them with the Assert That processor to check if a value is greater than, less than,
equal to, or close to an expected value.

> [!NOTE] `Comparable` is a DataWeave type that represents all the types that can be compared to
> each other.  
> Allowed primitives are String, Number, Boolean, DateTime, LocalDateTime, LocalTime, Time, and
> TimeZone that you can pass any primitive value such as an integer or a date.

## greaterThan(Comparable)

Checks that the expression is greater than the specified value.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::greaterThan(|2017-08-09|)]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::greaterThan(20)]"/>
```

## greaterThanOrEqualTo(Comparable)

Checks that the expression is greater than or equal to the specified value.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::greaterThanOrEqualTo(20)]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::greaterThanOrEqualTo(|2017-08-09|)]"/>
```

## lessThan(Comparable)

Checks that the expression is less than the specified value.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::lessThan(20)]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::lessThan(|2017-08-09|)]"/>
```

## lessThanOrEqualTo(Comparable)

Checks that the expression is less than or equal to the specified value.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::lessThanOrEqualTo(20)]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::lessThanOrEqualTo(|2017-08-09|)]"/>
```

## closeTo(Number, Number)

Checks that the expression is close to the first number, using the second number as a delta value.  
In other words, checks that the expression belongs to the range defined by the first number +/- the
second number.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::closeTo(1, 0.01)]"/>

<!--
  This evaluates if the expression is between 0.99 (1 - 0.01) and 1.01 (1 + 0.01)
-->
```

## equalTo(Object)

Checks that the expression is equal to a specific value.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::equalTo(0)]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::equalTo('example')]"/>
```

This matcher also accepts Dataweave objects.

Example

```xml
<munit-tools:assert-that
expression="#[{example1: 1 , example2: 2}]"
is="#[MunitTools::equalTo({example1: 1 , example2: 2})]"/>
```

The matcher validates that the keys and their respective values are the same.  
The order in the matcher must be the same as the one in the expression or the assertion fails.

Example

```xml
<munit-tools:assert-that
expression="#[{example1: 1 , example2: 2}]"
is="#[MunitTools::equalTo({example2: 2 , example1: 1})]"/>

<!-- This assertion fails -->
```

Example

```xml
<munit-tools:assert-that
expression="#[[1, 2, 3]]"
is="#[MunitTools::equalTo([3, 2, 1])]"/>

<!-- This assertion fails -->
```

## See Also

- [DataWeave Comparable Type](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_comparable)

- [MUnit Matchers](https://docs.mulesoft.com/munit/latest/munit-matchers)

- [Core Matchers Reference](https://docs.mulesoft.com/munit/latest/core-matchers-reference)

- [String Matchers Reference](https://docs.mulesoft.com/munit/latest/string-matchers-reference)

- [Iterable and Map Matchers Reference](https://docs.mulesoft.com/munit/latest/iterable-map-matchers-reference)

<!-- document id=e333c7b3cbecb2a5e38ddd8530955f3f2765015c91926f93f823acd1b2273e1d url=/mulesoft/current/en-us/munit/2.3/munit-cookbook.md -->

---
product: MUnit
version: 2.3
---

# MUnit Cookbook

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

This section links to examples that demonstrate common MUnit usages.

<table><colgroup><col> <col></colgroup><thead><tr><th>Example</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/2.3/mock-file-cookbook">Mocking Resources for Your Tests</a></p></div></div></td><td><div><div><p>Mocking test code for your MUnit tests.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/2.3/mock-before-after-foreach-cookbook">Mocking a Message Before and Inside a Foreach Processor</a></p></div></div></td><td><div><div><p>Mocking a processor that can return different payloads.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/2.3/test-mock-errors-cookbook">Testing and Mocking Errors</a></p></div></div></td><td><div><div><p>Mocking expected errors in your code.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/2.3/use-environment-properties-on-tests-cookbook">Testing with Environment Properties</a></p></div></div></td><td><div><div><p>Loading different environment values to your MUnit tests.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/2.3/utility-classes-cookbook">Using Utility Classes From a Test</a></p></div></div></td><td><div><div><p>Using custom Java classes in your MUnit tests.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/2.3/ftp-server-cookbook">Configuring FTP Server Utility in an MUnit Test</a></p></div></div></td><td><div><div><p>Configuring an FTP utility to test your FTP server connections.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/2.3/db-server-cookbook">Configuring DB Server Utility in an MUnit Test</a></p></div></div></td><td><div><div><p>Configuring a database utility to test your database connections.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/2.3/runtime-patching">Patching the Embedded Mule Runtime Engine Version</a></p></div></div></td><td><div><div><p>Configuring MUnit to run against a patched Mule runtime engine version.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/2.3/domain-based-application-cookbook">Test Domain-Based Applications</a></p></div></div></td><td><div><div><p>Testing Mule applications that inherit a Mule domain.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/2.3/test-flow-with-scheduler-cookbook">Testing a Flow with a Scheduler Source</a></p></div></div></td><td><div><div><p>Testing a flow that is triggered by a scheduler.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/2.3/test-recorder-examples">Recording a Test from an Exchange Example</a></p></div></div></td><td><div><div><p>Using the MUnit test recorder.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/2.3/test-processor-that-uses-target-variable">Testing a Processor That Stores Data in a Target Variable</a></p></div></div></td><td><div><div><p>Ensuring that the assertions check the content of the stored variable.</p></div></div></td></tr></tbody></table>

<!-- document id=9efd70677771936e5a8d763e1574c7369a26a03e3e532c824772444a32315fc1 url=/mulesoft/current/en-us/munit/3.6/munit-cookbook.md -->

---
product: MUnit
version: 3.6
---

# MUnit Cookbook

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

This section links to examples that demonstrate common MUnit usages.

<table><colgroup><col> <col></colgroup><thead><tr><th>Example</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/3.6/mock-file-cookbook">Mocking Resources for Your Tests</a></p></div></div></td><td><div><div><p>Mocking test code for your MUnit tests.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/3.6/mock-before-after-foreach-cookbook">Mocking a Message Before and Inside a Foreach Processor</a></p></div></div></td><td><div><div><p>Mocking a processor that can return different payloads.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/3.6/test-mock-errors-cookbook">Testing and Mocking Errors</a></p></div></div></td><td><div><div><p>Mocking expected errors in your code.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/3.6/use-environment-properties-on-tests-cookbook">Testing with Environment Properties</a></p></div></div></td><td><div><div><p>Loading different environment values to your MUnit tests.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/3.6/utility-classes-cookbook">Using Utility Classes From a Test</a></p></div></div></td><td><div><div><p>Using custom Java classes in your MUnit tests.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/3.6/ftp-server-cookbook">Configuring FTP Server Utility in an MUnit Test</a></p></div></div></td><td><div><div><p>Configuring an FTP utility to test your FTP server connections.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/3.6/db-server-cookbook">Configuring DB Server Utility in an MUnit Test</a></p></div></div></td><td><div><div><p>Configuring a database utility to test your database connections.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/3.6/runtime-patching">Patching the Embedded Mule Runtime Engine Version</a></p></div></div></td><td><div><div><p>Configuring MUnit to run against a patched Mule runtime engine version.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/3.6/domain-based-application-cookbook">Test Domain-Based Applications</a></p></div></div></td><td><div><div><p>Testing Mule applications that inherit a Mule domain.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/3.6/test-flow-with-scheduler-cookbook">Testing a Flow with a Scheduler Source</a></p></div></div></td><td><div><div><p>Testing a flow that is triggered by a scheduler.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/3.6/test-recorder-examples">Recording a Test from an Exchange Example</a></p></div></div></td><td><div><div><p>Using the MUnit test recorder.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/3.6/test-processor-that-uses-target-variable">Testing a Processor That Stores Data in a Target Variable</a></p></div></div></td><td><div><div><p>Ensuring that the assertions check the content of the stored variable.</p></div></div></td></tr></tbody></table>

<!-- document id=a89941dae94cd320a22cfaec71edfdb2a0905a34ca3e75e6b8254aec4c35fb74 url=/mulesoft/current/en-us/munit/latest/munit-cookbook.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit Cookbook

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

MUnit cookbooks are step-by-step examples that demonstrate common MUnit testing patterns, including
mocking, error handling, environment properties, and utility classes.

<table><colgroup><col> <col></colgroup><thead><tr><th>Example</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/latest/mock-file-cookbook">Mock Resources for MUnit Tests with DataWeave</a></p></div></div></td><td><div><div><p>Mocking test code for your MUnit tests.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/latest/mock-before-after-foreach-cookbook">Mock Messages Before and Inside a Foreach Processor in MUnit</a></p></div></div></td><td><div><div><p>Mocking a processor that can return different payloads.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/latest/test-mock-errors-cookbook">Test and Mock Errors in MUnit</a></p></div></div></td><td><div><div><p>Mocking expected errors in your code.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/latest/use-environment-properties-on-tests-cookbook">Test MUnit Flows with Environment Properties</a></p></div></div></td><td><div><div><p>Loading different environment values to your MUnit tests.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/latest/utility-classes-cookbook">Use Utility Classes in MUnit Tests</a></p></div></div></td><td><div><div><p>Using custom Java classes in your MUnit tests.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/latest/ftp-server-cookbook">Configure the MUnit FTP Server Utility</a></p></div></div></td><td><div><div><p>Configuring an FTP utility to test your FTP server connections.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/latest/db-server-cookbook">Configure the MUnit Database Server Utility</a></p></div></div></td><td><div><div><p>Configuring a database utility to test your database connections.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/latest/runtime-patching">Patch the Embedded Mule Runtime Engine Version in MUnit</a></p></div></div></td><td><div><div><p>Configuring MUnit to run against a patched Mule runtime engine version.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/latest/domain-based-application-cookbook">Test MUnit Domain-Based Applications</a></p></div></div></td><td><div><div><p>Testing Mule applications that inherit a Mule domain.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/latest/test-flow-with-scheduler-cookbook">Test a Flow with a Scheduler Source in MUnit</a></p></div></div></td><td><div><div><p>Testing a flow that is triggered by a scheduler.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/latest/test-recorder-examples">Record an MUnit Test from an Anypoint Exchange Example</a></p></div></div></td><td><div><div><p>Using the MUnit test recorder.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/latest/test-processor-that-uses-target-variable">Test MUnit Processors That Use Target Variables</a></p></div></div></td><td><div><div><p>Ensuring that the assertions check the content of the stored variable.</p></div></div></td></tr></tbody></table>

<!-- document id=b3b34b4b1badd013356230606d22ef2a58319c6704bb8eb67a669b50afaa754d url=/mulesoft/current/en-us/munit/latest/core-matchers-reference.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit Core Matchers Reference

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

MUnit core matchers are general-purpose matcher functions for use with the Assert That processor in
a MUnit test. Use them to check for null values, media types, encodings, and logical combinations of
other matchers.

## nullValue()

Checks that the expression is null.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::nullValue()]"/>
```

## notNullValue()

Checks that the expression is not null.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::notNullValue()]"/>
```

## withMediaType(String)

Checks that the expression’s media type is the one specified.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::withMediaType('text/xml')]"/>
```

## withEncoding(String)

Checks that the expression encoding is the one specified.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::withEncoding('UTF-8')]"/>
```

## both(Matcher, Matcher)

Checks that both provided matchers are successful.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::both(MunitTools::notNullValue(),MunitTools::equalTo('example'))]"/>
```

## either(Matcher,Matcher)

Checks that at least one of the matchers is successful.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::either(MunitTools::nullValue(),MunitTools::equalTo(0))]"/>
```

## not(Object)

Checks if the provided matcher is not successful.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::not(0)]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::not(MunitTools::equalTo(0))]"/>
```

## anyOf(Array<Matcher>)

Checks if any of the matchers are successful.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::anyOf([MunitTools::notNullValue(),MunitTools::withMediaType('text/xml'),MunitTools::isEmptyString()])]"/>
```

## allOf(Array<Matcher>)

Checks if all of the matchers are successful.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::allOf([MunitTools::notNullValue(),MunitTools::withMediaType('text/xml'),MunitTools::isEmptyString()])]"/>
```

## See Also

- [MUnit Matchers](https://docs.mulesoft.com/munit/latest/munit-matchers)

- [String Matchers Reference](https://docs.mulesoft.com/munit/latest/string-matchers-reference)

- [Comparable Matchers Reference](https://docs.mulesoft.com/munit/latest/comparable-matchers-reference)

- [Iterable and Map Matchers Reference](https://docs.mulesoft.com/munit/latest/iterable-map-matchers-reference)

<!-- document id=6199c0759a21f83132bca42175db8fef292a31866234f2b4c641bf8eb5deb7a8 url=/mulesoft/current/en-us/munit/latest/munit-coverage-report.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit Coverage Report

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The MUnit Coverage feature measures how much of a Mule application is executed by a set of MUnit
tests by counting event processors. Use it to track application, resource, and flow coverage metrics
and enforce quality standards.

- Application overall coverage: An average of the items below.

- Resource coverage: Refers to each Mule configuration file under src/main/mule.

- Flow coverage: Refers to any of the following components: Flows, Sub-flows, and Batch jobs.

Coverage report runs only for EE edition runtimes. If your application has a `requiredProduct` of a
Mule CE runtime you will see the following message: **Coverage is a EE only feature and you’ve
selected to run over CE**. To run against an EE runtime see
[Specifying the Runtime Product](https://docs.mulesoft.com/munit/latest/munit-maven-plugin#specify-runtime-product).

The following is a coverage report sample in JSON format.  
Use the code callouts below to understand each field in the report:

MUnit Coverage - sample JSON report

```json
{
  "coverage": 75.0, (1)
  "requiredApplicationCoverage": 40.0, (2)
  "requiredResourceCoverage": 30.0,    (2)
  "requiredFlowCoverage": 25.0,        (2)
  "flowCount": 3,             (3)
  "processorCount": 4,        (4)
  "coveredProcessorCount": 3, (5)
  "files": [ {
    "name": "file1.xml", (6)
    "flowCount": 1,      (7)
    "coverage": 100.0,   (8)
    "processorCount": 2, (9)
    "weight": 50.0,     (10)
    "flows": [ {
      "name": "file1Flow1", (11)
      "type": "FLOW",       (12)
      "coverage": 100.0,    (13)
      "messageProcessorCount": 2, (14)
      "coveredProcessorCount": 2, (15)
      "lines": [ { (16)
        "lineNumber": 11,
        "covered": true
      }, {
        "lineNumber": 12,
        "covered": true
      } ]
    } ]
  }, {
    "name": "file2.xml",
    "flowCount": 2,
    "coverage": 50.0,
    "processorCount": 2,
    "weight": 50.0,
    "flows": [ {
      "name": "file2Flow2",
      "type": "SCOPE",
      "coverage": 100.0,
      "messageProcessorCount": 1,
      "coveredProcessorCount": 1,
      "lines": [ {
        "lineNumber": 10,
        "covered": true
      } ]
    }, {
      "name": "file2Flow1",
      "type": "SCOPE",
      "coverage": 0.0,
      "messageProcessorCount": 1,
      "coveredProcessorCount": 0,
      "lines": [  {
        "lineNumber": 7,
        "covered": false
      } ]
    } ]
  } ]
}
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Coverage percentage of the whole application.</td></tr><tr><td><i data-value="2"></i><b>2</b></td><td>Required coverages for application, resources, and flows. If not configured, they default to -1.</td></tr><tr><td><i data-value="3"></i><b>3</b></td><td>Amount of flows in the application.</td></tr><tr><td><i data-value="4"></i><b>4</b></td><td>Amount of event processors in the application.</td></tr><tr><td><i data-value="5"></i><b>5</b></td><td>Amount of covered event processors.</td></tr><tr><td><i data-value="6"></i><b>6</b></td><td>Name of that file.</td></tr><tr><td><i data-value="7"></i><b>7</b></td><td>Amount of flows in that file.</td></tr><tr><td><i data-value="8"></i><b>8</b></td><td>Coverage percentage of that file.</td></tr><tr><td><i data-value="9"></i><b>9</b></td><td>Amount of event processors in that file.</td></tr><tr><td><i data-value="10"></i><b>10</b></td><td>Contribution of that file to the coverage percentage of the whole application.</td></tr><tr><td><i data-value="11"></i><b>11</b></td><td>Name of the flow.</td></tr><tr><td><i data-value="12"></i><b>12</b></td><td>Type of the top level element.<br>Other type of top level element in coverage is error-handler.</td></tr><tr><td><i data-value="13"></i><b>13</b></td><td>Coverage percentage of that flow.</td></tr><tr><td><i data-value="14"></i><b>14</b></td><td>Amount of event processors in that flow.</td></tr><tr><td><i data-value="15"></i><b>15</b></td><td>Amount of event processors covered in that flow.</td></tr><tr><td><i data-value="16"></i><b>16</b></td><td>XML line numbers containing event processors in that file, and whether they were covered or not.</td></tr></tbody></table>

## See Also

- [Coverage in Maven](https://docs.mulesoft.com/munit/latest/coverage-maven-concept)

<!-- document id=177ade6e09d34cef11bd0375c9ec67a15861d11ad49e3bf2631f6bde53120983 url=/mulesoft/current/en-us/munit/latest/dataweave-assertions-library.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit DataWeave Assertions Library

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The MUnit DataWeave Assertions Library is a set of DataWeave matcher functions for writing
assertions in MUnit tests. Use it with the Assert Expression processor to validate values such as
strings, numbers, arrays, and objects using DataWeave syntax.

## dw::test::Asserts

This module contains the set of core Matchers to use in your tests

Example

```dataweave
%dw 2.0
import dw::test::Asserts
---
payload must beObject()
```

Validates if a payload is of type Object

## Functions

### anyOf

#### anyOf(Array<Matcher<Any>>): Matcher<Any>

Validates that the value satisfies at least one of the given matchers

```dataweave
%dw 2.0
import dw::test::Asserts
---
"A Text" must anyOf([beObject(), beString()])
```

### beArray

#### beArray(): Matcher

Validates that a given value is of type Array

```dataweave
%dw 2.0
import dw::test::Asserts
---
[1, 4, 7] must beArray()
```

### beBlank

#### beBlank(): Matcher<String | Null>

Validates that the String value is blank

```dataweave
%dw 2.0
import dw::test::Asserts
---
"  " must beBlank()
```

### beBoolean

#### beBoolean(): Matcher

Validates that a given value is of type Boolean

```dataweave
%dw 2.0
import dw::test::Asserts
---
true must beBoolean()
```

### beEmpty

#### beEmpty(): Matcher<String | Object | Array | Null>

Validates that the value (String, Object or Array) is empty

```dataweave
%dw 2.0
import dw::test::Asserts
---
[] must beEmpty()
```

### beGreaterThan

#### beGreaterThan(Comparable, Boolean): Matcher<Comparable>

Validates that the asserted Comparable value is greater than the given one

Can be equal to when using the _inclusive_ argument

```dataweave
%dw 2.0
import dw::test::Asserts
---
3 must beGreaterThan(2)
```

### beLowerThan

#### beLowerThan(Comparable, Boolean): Matcher<Comparable>

Validates that the asserted Comparable value is lower than the given one

Can be equal to when using the _inclusive_ argument

```dataweave
%dw 2.0
import dw::test::Asserts
---
1 must beLowerThan(2)
```

### beNull

#### beNull(): Matcher

Validates that a given value is of type Null

```dataweave
%dw 2.0
import dw::test::Asserts
---
null must beNull()
```

### beNumber

#### beNumber(): Matcher

Validates that a given value is of type Number

```dataweave
%dw 2.0
import dw::test::Asserts
---
123 must beNumber()
```

### beObject

#### beObject(): Matcher

Validates that a given value is of type Object

```dataweave
%dw 2.0
import dw::test::Asserts
---
{ name : "Lionel", lastName: "Messi"} must beObject()
```

### beOneOf

#### beOneOf(Array<Any>): Matcher

Validates that the value is contained in the given Array

```dataweave
%dw 2.0
import dw::test::Asserts
---
1 must beOneOf([1, "A Text", true])
```

### beString

#### beString(): Matcher

Validates that a given value is of type String

```dataweave
%dw 2.0
import dw::test::Asserts
---
"A Text" must beString()
```

### contain

#### contain(String): Matcher<String>

Validates that the asserted String contains the given String

```dataweave
%dw 2.0
import dw::test::Asserts
---
"A Text" must contain("ex")
```

#### contain(Any): Matcher<Array<Any>>

Validates that the asserted Array contains the given value

```dataweave
%dw 2.0
import dw::test::Asserts
---
[1, "A Text", true] must contain(1)
```

### eachItem

#### eachItem(Matcher<Any>): Matcher<Array<Any>>

Validates that each item of the array satisfies the given matcher

```dataweave
%dw 2.0
import dw::test::Asserts
---
[1,2,3] must eachItem(beNumber())
```

### endWith

#### endWith(String): Matcher<String>

Validates that the asserted String ends with the given String

```dataweave
%dw 2.0
import dw::test::Asserts
---
"A Text" must endWith("xt")
```

### equalTo

#### equalTo(Any, { unordered?: Boolean }): Matcher<Any>

Validates that a value is equal to another one

```dataweave
%dw 2.0
import dw::test::Asserts
---
(1 + 2) must equalTo(3)
```

### equalToResource

#### equalToResource(String, String, Object): Matcher<Any>

Validates that the given value is equal to the content of a resource file

The resource file must belong to the classpath

```dataweave
%dw 2.0
import dw::test::Asserts
---
{ name: "Lionel", lastName: "Messi" } must equalToResource("user.json", "application/json")
```

### haveItem

#### haveItem(Matcher<Any>): Matcher<Array<Any>>

Validates that at least one item of the array satisfies the given matcher

```dataweave
%dw 2.0
import dw::test::Asserts
---
[1, true, "a text"] must haveItem(beNumber())
```

### haveKey

#### haveKey(String): Matcher<Object>

Validates that the Object has the given key

```dataweave
%dw 2.0
import dw::test::Asserts
---
{ name: "Lionel", lastName: "Messi" } must haveKey("name")
```

### haveSize

#### haveSize(Number): Matcher<Array | String | Object>

Validates that the array has the given size

```dataweave
%dw 2.0
import dw::test::Asserts
---
[1, 4, 7] must haveSize(3)
```

### haveValue

#### haveValue(Any): Matcher<Object>

Validates that the Object has the given value

```dataweave
%dw 2.0
import dw::test::Asserts
---
{ name: "Lionel", lastName: "Messi" } must haveValue("Messi")
```

### must

#### must(T, Array<(value: T) → Matcher<T> | MatcherResult | Boolean>): MatcherResult

This function allows to assert a value with a list of Matcher of Expressions

Example

```dataweave
%dw 2.0
import dw::test::Asserts
---
payload must [
    beObject(),
    $.foo is Null
]
```

#### must(T, (value: T) → Matcher<T> | Boolean): MatcherResult

This function allows to assert a value with a Matcher of Expressions

Example

```dataweave
%dw 2.0
import dw::test::Asserts
---
payload must beObject()
```

### notBe

#### notBe(Matcher<T>): Matcher<T>

Validates that the value doesn’t satisfy the given matcher

```dataweave
%dw 2.0
import dw::test::Asserts
---
1 must notBe(equalTo(2))
```

### notBeNull

#### notBeNull(): Matcher

Validates that a given value isn’t of type Null

```dataweave
%dw 2.0
import dw::test::Asserts
---
"A Text" must notBeNull()
```

### startWith

#### startWith(String): Matcher<String>

Validates that the asserted String starts with the given String

```dataweave
%dw 2.0
import dw::test::Asserts
---
"A Text" must startWith("A")
```

## Variables

### MATCHED

Constant that represents a successful match

## Types

### Matcher

Data Type that represents a Matcher to perform assertions

Example

```dataweave
%dw 2.0
import dw::test::Asserts

fun beEqualToOne(): Matcher<Any> =
    (actual) -> do {
        {
            matches: actual == 1,
            description: { expected: "To be 1", actual: write(actual) as String }
        }
    }
```

Definition

```dataweave
(value: T) -> MatcherResult
```

### MatcherResult

Data Type that represents the result of an Assertion

Example

```dataweave
{
  "matches": false,
  description : { expected : "Number type", actual: "A Text" }
}
```

Definition

```dataweave
{ matches: Boolean, description: { expected: String, actual: String }, reasons?: Array<String> }
```

<!-- document id=4f3c491fabeecdd538e4767495eedff73d0ea454e2188b2809bac33a70cf8c3d url=/mulesoft/current/en-us/munit/latest/dynamic-directories.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit Dynamic Directories

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The MUnit dynamic directories feature provides the `munit.temporary.directory` property to create
and manage temporary files and folders during a MUnit test. The temporary directory is deleted
automatically at the end of each test.

For example, using the file connector, you could configure the working directory as follows:

```xml
<file:config name="tmpDir">
    <file:connection workingDir="${munit.temporary.directory}"/>
</file:config>
```

And then use it to create files/folders inside it:

```xml
<file:create-directory config-ref="tmpDir" directoryPath="example"/>
```

## See Also

- [Dynamic Ports](https://docs.mulesoft.com/munit/latest/dynamic-ports)

<!-- document id=7465e958fa72e8e73e1cd880dc9870408d47314618add1c6da4034f6cd5dd0dd url=/mulesoft/current/en-us/munit/latest/dynamic-ports.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit Dynamic Ports

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The MUnit Dynamic Ports element binds a free port to a property at test runtime, preventing port
conflicts when running MUnit tests in parallel. You can optionally restrict the port search to a
specific range using min and max values.

For example, a dynamic port would look something like this:

```xml
<munit:dynamic-port propertyName="a.dynamic.port"/>
```

And it can be used in the http configuration:

```xml
<http:request-config name="httpRequestConfig">
    <http:request-connection host="localhost" port="${a.dynamic.port}"/>
</http:request-config>
```

Additionally you can set min and max values from where to get the port:

```xml
<munit:dynamic-port propertyName="a.dynamic.port" min="6000" max="7000"/>
```

## See Also

- [Dynamic Directories](https://docs.mulesoft.com/munit/latest/dynamic-directories)

- [Storage Event Processors](https://docs.mulesoft.com/munit/latest/storage-event-processors)

<!-- document id=57fea9f2a3eec192ac166935cac0571edc77ae258b68d5657221f71a40b4afeb url=/mulesoft/current/en-us/munit/2.3/event-processors.md -->

---
product: MUnit
version: 2.3
---

# MUnit Event Processors

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

MUnit has a set of dedicated event processors to validate, assert, and mock the content and status
of the Mule event so you can run automatic tests against your Mule applications.

## See Also

- [Assertion Event Processor](https://docs.mulesoft.com/munit/2.3/assertion-event-processor)

- [Set Event Processor](https://docs.mulesoft.com/munit/2.3/set-event-processor)

- [Mock When Event Processor](https://docs.mulesoft.com/munit/2.3/mock-event-processor)

- [Verify Event Processor](https://docs.mulesoft.com/munit/2.3/verify-event-processor)

- [Spy Event Processor](https://docs.mulesoft.com/munit/2.3/spy-event-processor)

- [Storage Event Processors](https://docs.mulesoft.com/munit/2.3/storage-event-processors)

- [Queue Event Processors](https://docs.mulesoft.com/munit/2.3/queue-processors)

<!-- document id=f2ab9daf091c91ffb9089aa32b963b8c7f07f2a62f7c6f10d28973f3d365ea67 url=/mulesoft/current/en-us/munit/3.6/event-processors.md -->

---
product: MUnit
version: 3.6
---

# MUnit Event Processors

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

MUnit has a set of dedicated event processors to validate, assert, and mock the content and status
of the Mule event so you can run automatic tests against your Mule applications.

## See Also

- [Assertion Event Processor](https://docs.mulesoft.com/munit/3.6/assertion-event-processor)

- [Set Event Processor](https://docs.mulesoft.com/munit/3.6/set-event-processor)

- [Mock When Event Processor](https://docs.mulesoft.com/munit/3.6/mock-event-processor)

- [Verify Event Processor](https://docs.mulesoft.com/munit/3.6/verify-event-processor)

- [Spy Event Processor](https://docs.mulesoft.com/munit/3.6/spy-event-processor)

- [Storage Event Processors](https://docs.mulesoft.com/munit/3.6/storage-event-processors)

- [Queue Event Processors](https://docs.mulesoft.com/munit/3.6/queue-processors)

<!-- document id=494959f47d582385b3616ff24ac1a5c79335b5d6ad505804015e8a9cf7470e3b url=/mulesoft/current/en-us/munit/latest/event-processors.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit Event Processors

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

MUnit event processors let you validate, assert, and mock the content and status of Mule events in
automated MUnit tests. Use them to verify that your Mule application behaves as expected during test
execution.

## See Also

- [Assertion Event Processor](https://docs.mulesoft.com/munit/latest/assertion-event-processor)

- [Set Event Processor](https://docs.mulesoft.com/munit/latest/set-event-processor)

- [Mock When Event Processor](https://docs.mulesoft.com/munit/latest/mock-event-processor)

- [Verify Event Processor](https://docs.mulesoft.com/munit/latest/verify-event-processor)

- [Spy Event Processor](https://docs.mulesoft.com/munit/latest/spy-event-processor)

- [Storage Event Processors](https://docs.mulesoft.com/munit/latest/storage-event-processors)

- [Queue Event Processors](https://docs.mulesoft.com/munit/latest/queue-processors)

<!-- document id=d5e981fc3abc30cf77c36eb069c25e58ea5744313834b2ac28a9dc45aea84c98 url=/mulesoft/current/en-us/munit/latest/fail-event-processor.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit Fail Event Processor

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The MUnit Fail event processor forces a MUnit test to fail at a specific point in the flow, which is
useful for validating that certain code paths are never reached. Use it to catch unexpected
execution paths during testing.

```xml
<munit-tools:fail
  message="This should fail"/>
```

The message field is optional and defines the error message to print when the assertion fails. The
processor throws a `MUNIT-TOOLS:ASSERTION_ERROR`.

<!-- document id=0c21640926ad374db95126b1aa3a2f3db12f8b34bef37f46ba975ecbfb7392d3 url=/mulesoft/current/en-us/munit/3.6/munit-in-acb.md -->

---
product: MUnit
version: 3.6
---

# MUnit in Anypoint Code Builder

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

MUnit is integrated with Anypoint Code Builder and you can:

- Create and design MUnit tests

- Run your tests

- View test results

- Debug your tests

<!-- document id=29a45943b9cbd70281a614775bdca3d0861d7d6f699588ece70fa343fc73eeb9 url=/mulesoft/current/en-us/munit/latest/munit-in-acb.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit in Anypoint Code Builder

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

MUnit is integrated with Anypoint Code Builder, letting you create, design, run, debug, and view
results of MUnit tests directly from the IDE. You can generate test structures from flows, configure
tests visually on the canvas, or write XML directly in the code editor. A dedicated Testing panel
lets you run all suites, individual suites, or specific test cases, and view results alongside
coverage metrics.

For full instructions, see
[Testing Projects with MUnit in Anypoint Code Builder](https://docs.mulesoft.com/anypoint-code-builder/int-test-munit).

<!-- document id=bfc6413584db0b92ea6003ea570f1b5129aac1546a4742d585833d131a664a7f url=/mulesoft/current/en-us/munit/3.6/munit-in-studio.md -->

---
product: MUnit
version: 3.6
---

# MUnit in Anypoint Studio

> 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

MUnit is fully integrated with Anypoint Studio. You can use the Studio graphical interface to:

- Create and design MUnit tests

- Run your tests

- View test results and coverage

- Debug your tests

## See Also

- [Scaffold a Template for an MUnit Test from an API Specification](https://docs.mulesoft.com/munit/3.6/munit-scaffold-test-task)

- [Test Recorder in Studio](https://docs.mulesoft.com/munit/3.6/test-recorder)

<!-- document id=2a745fc95e1b7e391fdeeb473813467c8c054d27c4cde4aa3750829b81175990 url=/mulesoft/current/en-us/munit/latest/munit-in-studio.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit in Anypoint Studio

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

MUnit is fully integrated with Anypoint Studio, letting you create, design, run, debug, and view
results of MUnit tests directly from the IDE. You can configure tests visually on the canvas or
write XML in the editor, and view test results and coverage metrics from the MUnit panel.

For full instructions, see
[Testing Projects with MUnit in Studio](https://docs.mulesoft.com/studio/test-with-munit-in-studio).

## See Also

- [Scaffold an MUnit Test Suite from an API Specification](https://docs.mulesoft.com/munit/latest/munit-scaffold-test-task)

- [MUnit Test Recorder in Anypoint Studio](https://docs.mulesoft.com/munit/latest/test-recorder)

<!-- document id=530d1ae5dc8233a5efa50a70f6889b6aafea55c3f6df7ee5c386286f72771267 url=/mulesoft/current/en-us/munit/2.3/munit-in-studio.md -->

---
product: MUnit
version: 2.3
---

# MUnit in Studio

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

MUnit is fully integrated with Anypoint Studio. You can use Studio’s graphical interface to:

- Create and design MUnit tests.

- Run your tests.

- View test results and coverage.

- Debug your tests.

## See Also

- [Scaffold a Template for an MUnit Test from an API Specification](https://docs.mulesoft.com/munit/2.3/munit-scaffold-test-task)

<!-- document id=f74f89b1bbd8375ffd3c7ee7ba5d1ef76c854e7a7d0d05f2ef9fd3aa7dcf12e7 url=/mulesoft/current/en-us/munit/latest/iterable-map-matchers-reference.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit Iterable and Map Matchers Reference

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

MUnit Iterable and Map matchers are matcher functions for asserting conditions on collections and
maps during a MUnit test. Use them with the Assert That processor to check items, keys, values, and
sizes of iterables and maps.

## everyItem(Matcher)

Checks that every element in the expression matches the specified matcher.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::everyItem(MunitTools::notNullValue())]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::everyItem(MunitTools::startsWith('a'))]"/>
```

## hasItem(Object)

Checks that any element in the expression matches the specified matcher.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasItem('example')]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasItem(MunitTools::startsWith('a'))]"/>
```

## hasSize(Matcher|Integer)

Checks that the size of the expression matches the specified matcher.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasSize(MunitTools::greaterThan(2))]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasSize(5)]"/>
```

## isEmpty()

Checks that the expression is an empty collection.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::isEmpty()]"/>
```

## hasKey(Matcher|String)

Checks that the expression has a key that matches the specified matcher.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasKey(MunitTools::startsWith('a'))]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasKey('mykey')]"/>
```

## hasValue(Object)

Checks that the expression has a value that matches the specified matcher.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasValue('myvalue')]"/>
```

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::hasValue(MunitTools::startsWith('a'))]"/>
```

## See Also

- [MUnit Matchers](https://docs.mulesoft.com/munit/latest/munit-matchers)

- [Core Matchers Reference](https://docs.mulesoft.com/munit/latest/core-matchers-reference)

- [String Matchers Reference](https://docs.mulesoft.com/munit/latest/string-matchers-reference)

- [Comparable Matchers Reference](https://docs.mulesoft.com/munit/latest/comparable-matchers-reference)

<!-- document id=7d496c42d0f5c752f535c51a3fd74bddc71e5ce2174bbb8bd953f89705f395b6 url=/mulesoft/current/en-us/munit/2.3/munit-matchers.md -->

---
product: MUnit
version: 2.3
keywords: munit, testing, unit testing
---

# MUnit Matchers

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

MUnit matchers are a set of DataWeave functions to define assertion conditions for any value in an
expression.

When defining matchers, include the prefix `MunitTools::` in the expression, as illustrated in the
following examples.

Matchers are grouped according to the type of conditions you want to validate.

## Match Core Values

Core matchers evaluate core values in the expression:

- Is the expression null?

- What is the media type or encoding of the expression?

- Does the expression return false?

- Are two evaluations successful?

Core Matchers:

- [nullValue()](https://docs.mulesoft.com/munit/2.3/core-matchers-reference#nullvalue) checks that the expression is null.

  Example:

  ```DataWeave
  #[MunitTools::nullValue()]
  ```

- [notNullValue()](https://docs.mulesoft.com/munit/2.3/core-matchers-reference#notnullvalue) checks that the expression is not null.

  Example:

  ```DataWeave
  #[MunitTools::notNullValue()]
  ```

- [withMediaType(String)](https://docs.mulesoft.com/munit/2.3/core-matchers-reference#withmediatype-string) checks that the expression’s
  media type is the one specified.

  Example:

  ```DataWeave
  #[MunitTools::withMediaType('text/xml')]
  ```

- [withEncoding(String)](https://docs.mulesoft.com/munit/2.3/core-matchers-reference#withencoding-string) checks that the expression’s
  encoding is the one specified.

  Example:

  ```DataWeave
  #[MunitTools::withEncoding('UTF-8')]
  ```

- [both(Matcher, Matcher)](https://docs.mulesoft.com/munit/2.3/core-matchers-reference#both-matcher-matcher) checks that both provided
  matchers are successful.

  Example:

  ```DataWeave
  #[MunitTools::both(MunitTools::notNullValue(), MunitTools::equalTo('example'))]
  ```

- [either(Matcher,Matcher)](https://docs.mulesoft.com/munit/2.3/core-matchers-reference#either-matcher-matcher) checks that at least one
  of the matchers is successful.

  Example:

  ```DataWeave
  #[MunitTools::either(MunitTools::nullValue(), MunitTools::equalTo(0))]
  ```

- [not(Matcher)](https://docs.mulesoft.com/munit/2.3/core-matchers-reference#not-matcher) checks if the provided matcher is not
  successful.

  Example:

  ```DataWeave
  #[MunitTools::not(MunitTools::equalTo(0))]
  ```

- [anyOf(Matchers\[\])](core-matchers-reference#anyof-matchers) checks if any of the matchers are
  successful.

  Example:

  ```DataWeave
  #[MunitTools::anyOf([MunitTools::notNullValue(),MunitTools::withMediaType('text/xml'),MunitTools::isEmptyString()])]
  ```

- [allOf(Matchers\[\])](core-matchers-reference#allof-matchers) checks if all of the matchers are
  successful.

  Example:

  ```DataWeave
  #[MunitTools::allOf([MunitTools::notNullValue(),MunitTools::withMediaType('text/xml'),MunitTools::isEmptyString()])]
  ```

## Match Strings

String Matchers perform assertions on String expressions:

- Does the expression contain a specified string?

- Does the expression start or end with a specified string?

- Does the string in the expression have zero length?

- Does the string in the expression match a specified string?

String Matchers:

- [containsString(String)](https://docs.mulesoft.com/munit/2.3/string-matchers-reference#containsstring-string) checks that the
  expression contains the specified String.

  Example:

  ```DataWeave
  #[MunitTools::containsString('example')]
  ```

- [startsWith(String)](https://docs.mulesoft.com/munit/2.3/string-matchers-reference#startswith-string) checks that the expression
  starts with the specified String.

  Example:

  ```DataWeave
  #[MunitTools::startsWith('exam')]
  ```

- [endsWith(String)](https://docs.mulesoft.com/munit/2.3/string-matchers-reference#endswith-string) checks that the expression ends with
  the specified String.

  Example:

  ```DataWeave
  #[MunitTools::endsWith('ple')]
  ```

- [isEmptyString()](https://docs.mulesoft.com/munit/2.3/string-matchers-reference#isemptystring) checks that the expression has zero
  length.

  Example:

  ```DataWeave
  #[MunitTools::isEmptyString()]
  ```

- [isEmptyOrNullString()](https://docs.mulesoft.com/munit/2.3/string-matchers-reference#isemptyornullstring) checks that the expression
  is null, or has zero length.

  Example:

  ```DataWeave
  #[MunitTools::isEmptyOrNullString()]
  ```

- [equalToIgnoringCase(String)](https://docs.mulesoft.com/munit/2.3/string-matchers-reference#equaltoignoringcase-string) checks that
  the expression is equal to the specified String, ignoring case.

  Example:

  ```DataWeave
  #[MunitTools::equalToIgnoringCase('example')]
  ```

- [equalToIgnoringWhiteSpace(String)](https://docs.mulesoft.com/munit/2.3/string-matchers-reference#equaltoignoringwhitespace-string)
  checks that the expression is equal to the string disregarding leading and trailing white spaces,
  and compressing all inner white spaces to a single space.

  Example:

  ```DataWeave
  #[MunitTools::equalToIgnoringWhiteSpace('An Example')]
  ```

- [stringContainsInOrder(String, String,…​)](https://docs.mulesoft.com/munit/2.3/string-matchers-reference#stringcontainsinorder-array-string)
  checks that the expression contains all of the specified substrings, regardless of the order of
  their appearance.

  Example:

  ```DataWeave
  is="#[MunitTools::stringContainsInOrder(['an', 'example'])]"/>
  ```

## Match Comparable Expressions

Comparable matchers compare the expression against a specified value:

- Is the expression’s value bigger or smaller than a specified value?

- Is the expression’s value closer to a specific number?

Some comparable matchers take a `Comparable` type. `Comparable` is a DataWeave type that represents
all the types that can be compared to each other. Allowed primitives are `String`, `Number`,
`Boolean`, `DateTime`, `LocalDateTime`, `LocalTime`, `Time`, and `TimeZone`.

Comparable Matchers:

- [greaterThan(Comparable)](https://docs.mulesoft.com/munit/2.3/comparable-matchers-reference#greaterthan-comparable) checks that the
  expression is greater than the specified value.

  Examples:

  ```DataWeave
  #[MunitTools::greaterThan(20)]
  ```

  ```DataWeave
  #[MunitTools::greaterThan(|2017-08-09|)]
  ```

- [greaterThanOrEqualTo(Comparable)](https://docs.mulesoft.com/munit/2.3/comparable-matchers-reference#greaterthanorequalto-comparable)
  checks that the expression is greater than or equal to the specified value.

  Examples:

  ```DataWeave
  #[MunitTools::greaterThanOrEqualTo(20)]
  ```

  ```DataWeave
  #[MunitTools::greaterThanOrEqualTo(|2017-08-09|)]
  ```

- [lessThan(Comparable)](https://docs.mulesoft.com/munit/2.3/comparable-matchers-reference#lessthan-comparable) checks that the
  expression is less than the specified value.

  Examples:

  ```DataWeave
  #[MunitTools::lessThan(20)
  ```

  ```DataWeave
  #[MunitTools::lessThan(|2017-08-09|)]
  ```

- [lessThanOrEqualTo(Comparable)](https://docs.mulesoft.com/munit/2.3/comparable-matchers-reference#lessthanorequalto-comparable) checks
  that the expression is less than or equal to the specified value.

  Examples:

  ```DataWeave
  #[MunitTools::lessThanOrEqualTo(20)]
  ```

  ```DataWeave
  #[MunitTools::lessThanOrEqualTo(|2017-08-09|)]
  ```

- [closeTo(Number, Number)](https://docs.mulesoft.com/munit/2.3/comparable-matchers-reference#closeto-number-number) checks that the
  expression is in the range defined by the first and second number.

  Example:

  ```DataWeave
  #[MunitTools::closeTo(1, 0.01)]
  ```

- [equalTo(Object)](https://docs.mulesoft.com/munit/2.3/comparable-matchers-reference#equalto-object) checks that the expression is
  equal to a specified value. This matcher also accepts DataWeave objects.

  Examples:

  ```DataWeave
  #[MunitTools::equalTo('example')]
  ```

  ```DataWeave
  #[MunitTools::equalTo({example1: 1 , example2: 2}]
  ```

## Match Maps and Iterations

Use iterable matchers and maps matchers when your expression is an array or a map of data:

- Is the map or array in the expression empty?

- Does the map or array in the expression have a specific key?

- Is every item in the array from the expression greater than or less than a specific number?

- Does any item in the array from the expression start or end with a specified string?

Iterable and Map Matchers:

- [everyItem(Matcher)](https://docs.mulesoft.com/munit/2.3/iterable-map-matchers-reference#everyitem-matcher) checks that every element
  in the expression matches the specified matcher. This matcher works only for arrays.

  Examples:

  ```DataWeave
  #[MunitTools::everyItem(MunitTools::notNullValue())]
  ```

  ```DataWeave
  #[MunitTools::everyItem(MunitTools::startsWith('a'))]
  ```

- [hasItem(Matcher)](https://docs.mulesoft.com/munit/2.3/iterable-map-matchers-reference#hasitem-matcher) checks that any element in the
  expression matches the specified matcher. This matcher works only for arrays.

  Examples:

  ```DataWeave
  #[MunitTools::hasItem(MunitTools::notNullValue())]
  ```

  ```DataWeave
  #[MunitTools::hasItem(MunitTools::startsWith('a'))]
  ```

- [hasSize(Matcher)](https://docs.mulesoft.com/munit/2.3/iterable-map-matchers-reference#hassize-matcher) checks that the size of the
  expression matches the specified matcher.

  Examples:

  ```DataWeave
  #[MunitTools::hasSize(MunitTools::equalTo(5))]
  ```

  ```DataWeave
  #[MunitTools::hasSize(MunitTools::greaterThan(5))]
  ```

- [isEmpty()](https://docs.mulesoft.com/munit/2.3/iterable-map-matchers-reference#isempty) checks that the expression is an empty
  collection.

  Examples:

  ```DataWeave
  #[MunitTools::isEmpty()]
  ```

- [hasKey(Matcher)](https://docs.mulesoft.com/munit/2.3/iterable-map-matchers-reference#haskey-matcher) checks that the expression has a
  key that matches the specified matcher. This matcher works only for maps.

  Examples:

  ```DataWeave
  #[MunitTools::hasKey(MunitTools::equalTo('myKey'))]
  ```

  ```DataWeave
  #[MunitTools::hasKey(MunitTools::startsWith('a'))]
  ```

- [hasValue(Matcher)](https://docs.mulesoft.com/munit/2.3/iterable-map-matchers-reference#hasvalue-matcher) checks that the expression
  has a value that matches the specified matcher. This matcher works only for maps.

  Examples:

  ```DataWeave
  #[MunitTools::hasValue(MunitTools::equalTo('myValue'))]
  ```

  ```DataWeave
  #[MunitTools::hasValue(MunitTools::startsWith('a'))]
  ```

## See Also

- [Core Matchers Reference](https://docs.mulesoft.com/munit/2.3/core-matchers-reference)

- [String Matchers Reference](https://docs.mulesoft.com/munit/2.3/string-matchers-reference)

- [Iterable and Map Matchers Reference](https://docs.mulesoft.com/munit/2.3/iterable-map-matchers-reference)

- [Assert That Event Processor](https://docs.mulesoft.com/munit/2.3/assertion-event-processor)

<!-- document id=9698e3f54ce95f7fa4284737dc35ed8fe51c69fe13bf689eaeadaf66b4ad8c33 url=/mulesoft/current/en-us/munit/3.6/munit-matchers.md -->

---
product: MUnit
version: 3.6
keywords: munit, testing, unit testing
---

# MUnit Matchers

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

MUnit matchers are a set of DataWeave functions to define assertion conditions for any value in an
expression.

When defining matchers, include the prefix `MunitTools::` in the expression, as illustrated in the
following examples.

Matchers are grouped according to the type of conditions you want to validate.

## Match Core Values

Core matchers evaluate core values in the expression:

- Is the expression null?

- What is the media type or encoding of the expression?

- Does the expression return false?

- Are two evaluations successful?

Core Matchers:

- [nullValue()](https://docs.mulesoft.com/munit/3.6/core-matchers-reference#nullvalue) checks that the expression is null.

  Example:

  ```DataWeave
  #[MunitTools::nullValue()]
  ```

- [notNullValue()](https://docs.mulesoft.com/munit/3.6/core-matchers-reference#notnullvalue) checks that the expression is not null.

  Example:

  ```DataWeave
  #[MunitTools::notNullValue()]
  ```

- [withMediaType(String)](https://docs.mulesoft.com/munit/3.6/core-matchers-reference#withmediatype-string) checks that the expression’s
  media type is the one specified.

  Example:

  ```DataWeave
  #[MunitTools::withMediaType('text/xml')]
  ```

- [withEncoding(String)](https://docs.mulesoft.com/munit/3.6/core-matchers-reference#withencoding-string) checks that the expression’s
  encoding is the one specified.

  Example:

  ```DataWeave
  #[MunitTools::withEncoding('UTF-8')]
  ```

- [both(Matcher, Matcher)](https://docs.mulesoft.com/munit/3.6/core-matchers-reference#both-matcher-matcher) checks that both provided
  matchers are successful.

  Example:

  ```DataWeave
  #[MunitTools::both(MunitTools::notNullValue(), MunitTools::equalTo('example'))]
  ```

- [either(Matcher,Matcher)](https://docs.mulesoft.com/munit/3.6/core-matchers-reference#either-matcher-matcher) checks that at least one
  of the matchers is successful.

  Example:

  ```DataWeave
  #[MunitTools::either(MunitTools::nullValue(), MunitTools::equalTo(0))]
  ```

- [not(Matcher)](https://docs.mulesoft.com/munit/3.6/core-matchers-reference#not-matcher) checks if the provided matcher is not
  successful.

  Example:

  ```DataWeave
  #[MunitTools::not(MunitTools::equalTo(0))]
  ```

- [anyOf(Matchers\[\])](core-matchers-reference#anyof-matchers) checks if any of the matchers are
  successful.

  Example:

  ```DataWeave
  #[MunitTools::anyOf([MunitTools::notNullValue(),MunitTools::withMediaType('text/xml'),MunitTools::isEmptyString()])]
  ```

- [allOf(Matchers\[\])](core-matchers-reference#allof-matchers) checks if all of the matchers are
  successful.

  Example:

  ```DataWeave
  #[MunitTools::allOf([MunitTools::notNullValue(),MunitTools::withMediaType('text/xml'),MunitTools::isEmptyString()])]
  ```

## Match Strings

String Matchers perform assertions on String expressions:

- Does the expression contain a specified string?

- Does the expression start or end with a specified string?

- Does the string in the expression have zero length?

- Does the string in the expression match a specified string?

String Matchers:

- [containsString(String)](https://docs.mulesoft.com/munit/3.6/string-matchers-reference#containsstring-string) checks that the
  expression contains the specified String.

  Example:

  ```DataWeave
  #[MunitTools::containsString('example')]
  ```

- [startsWith(String)](https://docs.mulesoft.com/munit/3.6/string-matchers-reference#startswith-string) checks that the expression
  starts with the specified String.

  Example:

  ```DataWeave
  #[MunitTools::startsWith('exam')]
  ```

- [endsWith(String)](https://docs.mulesoft.com/munit/3.6/string-matchers-reference#endswith-string) checks that the expression ends with
  the specified String.

  Example:

  ```DataWeave
  #[MunitTools::endsWith('ple')]
  ```

- [isEmptyString()](https://docs.mulesoft.com/munit/3.6/string-matchers-reference#isemptystring) checks that the expression has zero
  length.

  Example:

  ```DataWeave
  #[MunitTools::isEmptyString()]
  ```

- [isEmptyOrNullString()](https://docs.mulesoft.com/munit/3.6/string-matchers-reference#isemptyornullstring) checks that the expression
  is null, or has zero length.

  Example:

  ```DataWeave
  #[MunitTools::isEmptyOrNullString()]
  ```

- [equalToIgnoringCase(String)](https://docs.mulesoft.com/munit/3.6/string-matchers-reference#equaltoignoringcase-string) checks that
  the expression is equal to the specified String, ignoring case.

  Example:

  ```DataWeave
  #[MunitTools::equalToIgnoringCase('example')]
  ```

- [equalToIgnoringWhiteSpace(String)](https://docs.mulesoft.com/munit/3.6/string-matchers-reference#equaltoignoringwhitespace-string)
  checks that the expression is equal to the string disregarding leading and trailing white spaces,
  and compressing all inner white spaces to a single space.

  Example:

  ```DataWeave
  #[MunitTools::equalToIgnoringWhiteSpace('An Example')]
  ```

- [stringContainsInOrder(String, String,…​)](https://docs.mulesoft.com/munit/3.6/string-matchers-reference#stringcontainsinorder-array-string)
  checks that the expression contains all of the specified substrings, regardless of the order of
  their appearance.

  Example:

  ```DataWeave
  is="#[MunitTools::stringContainsInOrder(['an', 'example'])]"/>
  ```

## Match Comparable Expressions

Comparable matchers compare the expression against a specified value:

- Is the expression’s value bigger or smaller than a specified value?

- Is the expression’s value closer to a specific number?

Some comparable matchers take a `Comparable` type. `Comparable` is a DataWeave type that represents
all the types that can be compared to each other. Allowed primitives are `String`, `Number`,
`Boolean`, `DateTime`, `LocalDateTime`, `LocalTime`, `Time`, and `TimeZone`.

Comparable Matchers:

- [greaterThan(Comparable)](https://docs.mulesoft.com/munit/3.6/comparable-matchers-reference#greaterthan-comparable) checks that the
  expression is greater than the specified value.

  Examples:

  ```DataWeave
  #[MunitTools::greaterThan(20)]
  ```

  ```DataWeave
  #[MunitTools::greaterThan(|2017-08-09|)]
  ```

- [greaterThanOrEqualTo(Comparable)](https://docs.mulesoft.com/munit/3.6/comparable-matchers-reference#greaterthanorequalto-comparable)
  checks that the expression is greater than or equal to the specified value.

  Examples:

  ```DataWeave
  #[MunitTools::greaterThanOrEqualTo(20)]
  ```

  ```DataWeave
  #[MunitTools::greaterThanOrEqualTo(|2017-08-09|)]
  ```

- [lessThan(Comparable)](https://docs.mulesoft.com/munit/3.6/comparable-matchers-reference#lessthan-comparable) checks that the
  expression is less than the specified value.

  Examples:

  ```DataWeave
  #[MunitTools::lessThan(20)
  ```

  ```DataWeave
  #[MunitTools::lessThan(|2017-08-09|)]
  ```

- [lessThanOrEqualTo(Comparable)](https://docs.mulesoft.com/munit/3.6/comparable-matchers-reference#lessthanorequalto-comparable) checks
  that the expression is less than or equal to the specified value.

  Examples:

  ```DataWeave
  #[MunitTools::lessThanOrEqualTo(20)]
  ```

  ```DataWeave
  #[MunitTools::lessThanOrEqualTo(|2017-08-09|)]
  ```

- [closeTo(Number, Number)](https://docs.mulesoft.com/munit/3.6/comparable-matchers-reference#closeto-number-number) checks that the
  expression is in the range defined by the first and second number.

  Example:

  ```DataWeave
  #[MunitTools::closeTo(1, 0.01)]
  ```

- [equalTo(Object)](https://docs.mulesoft.com/munit/3.6/comparable-matchers-reference#equalto-object) checks that the expression is
  equal to a specified value. This matcher also accepts DataWeave objects.

  Examples:

  ```DataWeave
  #[MunitTools::equalTo('example')]
  ```

  ```DataWeave
  #[MunitTools::equalTo({example1: 1 , example2: 2}]
  ```

## Match Maps and Iterations

Use iterable matchers and maps matchers when your expression is an array or a map of data:

- Is the map or array in the expression empty?

- Does the map or array in the expression have a specific key?

- Is every item in the array from the expression greater than or less than a specific number?

- Does any item in the array from the expression start or end with a specified string?

Iterable and Map Matchers:

- [everyItem(Matcher)](https://docs.mulesoft.com/munit/3.6/iterable-map-matchers-reference#everyitem-matcher) checks that every element
  in the expression matches the specified matcher. This matcher works only for arrays.

  Examples:

  ```DataWeave
  #[MunitTools::everyItem(MunitTools::notNullValue())]
  ```

  ```DataWeave
  #[MunitTools::everyItem(MunitTools::startsWith('a'))]
  ```

- [hasItem(Matcher)](https://docs.mulesoft.com/munit/3.6/iterable-map-matchers-reference#hasitem-matcher) checks that any element in the
  expression matches the specified matcher. This matcher works only for arrays.

  Examples:

  ```DataWeave
  #[MunitTools::hasItem(MunitTools::notNullValue())]
  ```

  ```DataWeave
  #[MunitTools::hasItem(MunitTools::startsWith('a'))]
  ```

- [hasSize(Matcher)](https://docs.mulesoft.com/munit/3.6/iterable-map-matchers-reference#hassize-matcher) checks that the size of the
  expression matches the specified matcher.

  Examples:

  ```DataWeave
  #[MunitTools::hasSize(MunitTools::equalTo(5))]
  ```

  ```DataWeave
  #[MunitTools::hasSize(MunitTools::greaterThan(5))]
  ```

- [isEmpty()](https://docs.mulesoft.com/munit/3.6/iterable-map-matchers-reference#isempty) checks that the expression is an empty
  collection.

  Examples:

  ```DataWeave
  #[MunitTools::isEmpty()]
  ```

- [hasKey(Matcher)](https://docs.mulesoft.com/munit/3.6/iterable-map-matchers-reference#haskey-matcher) checks that the expression has a
  key that matches the specified matcher. This matcher works only for maps.

  Examples:

  ```DataWeave
  #[MunitTools::hasKey(MunitTools::equalTo('myKey'))]
  ```

  ```DataWeave
  #[MunitTools::hasKey(MunitTools::startsWith('a'))]
  ```

- [hasValue(Matcher)](https://docs.mulesoft.com/munit/3.6/iterable-map-matchers-reference#hasvalue-matcher) checks that the expression
  has a value that matches the specified matcher. This matcher works only for maps.

  Examples:

  ```DataWeave
  #[MunitTools::hasValue(MunitTools::equalTo('myValue'))]
  ```

  ```DataWeave
  #[MunitTools::hasValue(MunitTools::startsWith('a'))]
  ```

## See Also

- [Core Matchers Reference](https://docs.mulesoft.com/munit/3.6/core-matchers-reference)

- [String Matchers Reference](https://docs.mulesoft.com/munit/3.6/string-matchers-reference)

- [Iterable and Map Matchers Reference](https://docs.mulesoft.com/munit/3.6/iterable-map-matchers-reference)

- [Assert That Event Processor](https://docs.mulesoft.com/munit/3.6/assertion-event-processor)

<!-- document id=d34ef9d70c7f6e6e424f8e1a5d14e256dba8cb09cd8b473f5741e6ee6f572008 url=/mulesoft/current/en-us/munit/latest/munit-matchers.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
keywords: munit, testing, unit testing
---

# MUnit Matchers

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

MUnit matchers are DataWeave functions that define assertion conditions for any value in an
expression, used with the Assert That processor. Include the prefix `MunitTools::` when using them,
and choose from core, string, comparable, or iterable and map matcher groups depending on the type
of value you want to validate.

## Match Core Values

Core matchers evaluate core values in the expression:

- Is the expression null?

- What is the media type or encoding of the expression?

- Does the expression return false?

- Are two evaluations successful?

Core Matchers:

- [nullValue()](https://docs.mulesoft.com/munit/latest/core-matchers-reference#nullvalue) checks that the expression is null.

  Example:

  ```DataWeave
  #[MunitTools::nullValue()]
  ```

- [notNullValue()](https://docs.mulesoft.com/munit/latest/core-matchers-reference#notnullvalue) checks that the expression is not null.

  Example:

  ```DataWeave
  #[MunitTools::notNullValue()]
  ```

- [withMediaType(String)](https://docs.mulesoft.com/munit/latest/core-matchers-reference#withmediatype-string) checks that the expression’s
  media type is the one specified.

  Example:

  ```DataWeave
  #[MunitTools::withMediaType('text/xml')]
  ```

- [withEncoding(String)](https://docs.mulesoft.com/munit/latest/core-matchers-reference#withencoding-string) checks that the expression’s
  encoding is the one specified.

  Example:

  ```DataWeave
  #[MunitTools::withEncoding('UTF-8')]
  ```

- [both(Matcher, Matcher)](https://docs.mulesoft.com/munit/latest/core-matchers-reference#both-matcher-matcher) checks that both provided
  matchers are successful.

  Example:

  ```DataWeave
  #[MunitTools::both(MunitTools::notNullValue(), MunitTools::equalTo('example'))]
  ```

- [either(Matcher,Matcher)](https://docs.mulesoft.com/munit/latest/core-matchers-reference#either-matcher-matcher) checks that at least one
  of the matchers is successful.

  Example:

  ```DataWeave
  #[MunitTools::either(MunitTools::nullValue(), MunitTools::equalTo(0))]
  ```

- [not(Matcher)](https://docs.mulesoft.com/munit/latest/core-matchers-reference#not-matcher) checks if the provided matcher is not
  successful.

  Example:

  ```DataWeave
  #[MunitTools::not(MunitTools::equalTo(0))]
  ```

- [anyOf(Matchers\[\])](core-matchers-reference#anyof-matchers) checks if any of the matchers are
  successful.

  Example:

  ```DataWeave
  #[MunitTools::anyOf([MunitTools::notNullValue(),MunitTools::withMediaType('text/xml'),MunitTools::isEmptyString()])]
  ```

- [allOf(Matchers\[\])](core-matchers-reference#allof-matchers) checks if all of the matchers are
  successful.

  Example:

  ```DataWeave
  #[MunitTools::allOf([MunitTools::notNullValue(),MunitTools::withMediaType('text/xml'),MunitTools::isEmptyString()])]
  ```

## Match Strings

String Matchers perform assertions on String expressions:

- Does the expression contain a specified string?

- Does the expression start or end with a specified string?

- Does the string in the expression have zero length?

- Does the string in the expression match a specified string?

String Matchers:

- [containsString(String)](https://docs.mulesoft.com/munit/latest/string-matchers-reference#containsstring-string) checks that the
  expression contains the specified String.

  Example:

  ```DataWeave
  #[MunitTools::containsString('example')]
  ```

- [startsWith(String)](https://docs.mulesoft.com/munit/latest/string-matchers-reference#startswith-string) checks that the expression
  starts with the specified String.

  Example:

  ```DataWeave
  #[MunitTools::startsWith('exam')]
  ```

- [endsWith(String)](https://docs.mulesoft.com/munit/latest/string-matchers-reference#endswith-string) checks that the expression ends with
  the specified String.

  Example:

  ```DataWeave
  #[MunitTools::endsWith('ple')]
  ```

- [isEmptyString()](https://docs.mulesoft.com/munit/latest/string-matchers-reference#isemptystring) checks that the expression has zero
  length.

  Example:

  ```DataWeave
  #[MunitTools::isEmptyString()]
  ```

- [isEmptyOrNullString()](https://docs.mulesoft.com/munit/latest/string-matchers-reference#isemptyornullstring) checks that the expression
  is null, or has zero length.

  Example:

  ```DataWeave
  #[MunitTools::isEmptyOrNullString()]
  ```

- [equalToIgnoringCase(String)](https://docs.mulesoft.com/munit/latest/string-matchers-reference#equaltoignoringcase-string) checks that
  the expression is equal to the specified String, ignoring case.

  Example:

  ```DataWeave
  #[MunitTools::equalToIgnoringCase('example')]
  ```

- [equalToIgnoringWhiteSpace(String)](https://docs.mulesoft.com/munit/latest/string-matchers-reference#equaltoignoringwhitespace-string)
  checks that the expression is equal to the string disregarding leading and trailing white spaces,
  and compressing all inner white spaces to a single space.

  Example:

  ```DataWeave
  #[MunitTools::equalToIgnoringWhiteSpace('An Example')]
  ```

- [stringContainsInOrder(String, String,…​)](https://docs.mulesoft.com/munit/latest/string-matchers-reference#stringcontainsinorder-array-string)
  checks that the expression contains all of the specified substrings, regardless of the order of
  their appearance.

  Example:

  ```DataWeave
  is="#[MunitTools::stringContainsInOrder(['an', 'example'])]"/>
  ```

## Match Comparable Expressions

Comparable matchers compare the expression against a specified value:

- Is the expression’s value bigger or smaller than a specified value?

- Is the expression’s value closer to a specific number?

Some comparable matchers take a `Comparable` type. `Comparable` is a DataWeave type that represents
all the types that can be compared to each other. Allowed primitives are `String`, `Number`,
`Boolean`, `DateTime`, `LocalDateTime`, `LocalTime`, `Time`, and `TimeZone`.

Comparable Matchers:

- [greaterThan(Comparable)](https://docs.mulesoft.com/munit/latest/comparable-matchers-reference#greaterthan-comparable) checks that the
  expression is greater than the specified value.

  Examples:

  ```DataWeave
  #[MunitTools::greaterThan(20)]
  ```

  ```DataWeave
  #[MunitTools::greaterThan(|2017-08-09|)]
  ```

- [greaterThanOrEqualTo(Comparable)](https://docs.mulesoft.com/munit/latest/comparable-matchers-reference#greaterthanorequalto-comparable)
  checks that the expression is greater than or equal to the specified value.

  Examples:

  ```DataWeave
  #[MunitTools::greaterThanOrEqualTo(20)]
  ```

  ```DataWeave
  #[MunitTools::greaterThanOrEqualTo(|2017-08-09|)]
  ```

- [lessThan(Comparable)](https://docs.mulesoft.com/munit/latest/comparable-matchers-reference#lessthan-comparable) checks that the
  expression is less than the specified value.

  Examples:

  ```DataWeave
  #[MunitTools::lessThan(20)
  ```

  ```DataWeave
  #[MunitTools::lessThan(|2017-08-09|)]
  ```

- [lessThanOrEqualTo(Comparable)](https://docs.mulesoft.com/munit/latest/comparable-matchers-reference#lessthanorequalto-comparable) checks
  that the expression is less than or equal to the specified value.

  Examples:

  ```DataWeave
  #[MunitTools::lessThanOrEqualTo(20)]
  ```

  ```DataWeave
  #[MunitTools::lessThanOrEqualTo(|2017-08-09|)]
  ```

- [closeTo(Number, Number)](https://docs.mulesoft.com/munit/latest/comparable-matchers-reference#closeto-number-number) checks that the
  expression is in the range defined by the first and second number.

  Example:

  ```DataWeave
  #[MunitTools::closeTo(1, 0.01)]
  ```

- [equalTo(Object)](https://docs.mulesoft.com/munit/latest/comparable-matchers-reference#equalto-object) checks that the expression is
  equal to a specified value. This matcher also accepts DataWeave objects.

  Examples:

  ```DataWeave
  #[MunitTools::equalTo('example')]
  ```

  ```DataWeave
  #[MunitTools::equalTo({example1: 1 , example2: 2}]
  ```

## Match Maps and Iterations

Use iterable matchers and maps matchers when your expression is an array or a map of data:

- Is the map or array in the expression empty?

- Does the map or array in the expression have a specific key?

- Is every item in the array from the expression greater than or less than a specific number?

- Does any item in the array from the expression start or end with a specified string?

Iterable and Map Matchers:

- [everyItem(Matcher)](https://docs.mulesoft.com/munit/latest/iterable-map-matchers-reference#everyitem-matcher) checks that every element
  in the expression matches the specified matcher. This matcher works only for arrays.

  Examples:

  ```DataWeave
  #[MunitTools::everyItem(MunitTools::notNullValue())]
  ```

  ```DataWeave
  #[MunitTools::everyItem(MunitTools::startsWith('a'))]
  ```

- [hasItem(Matcher)](https://docs.mulesoft.com/munit/latest/iterable-map-matchers-reference#hasitem-matcher) checks that any element in the
  expression matches the specified matcher. This matcher works only for arrays.

  Examples:

  ```DataWeave
  #[MunitTools::hasItem(MunitTools::notNullValue())]
  ```

  ```DataWeave
  #[MunitTools::hasItem(MunitTools::startsWith('a'))]
  ```

- [hasSize(Matcher)](https://docs.mulesoft.com/munit/latest/iterable-map-matchers-reference#hassize-matcher) checks that the size of the
  expression matches the specified matcher.

  Examples:

  ```DataWeave
  #[MunitTools::hasSize(MunitTools::equalTo(5))]
  ```

  ```DataWeave
  #[MunitTools::hasSize(MunitTools::greaterThan(5))]
  ```

- [isEmpty()](https://docs.mulesoft.com/munit/latest/iterable-map-matchers-reference#isempty) checks that the expression is an empty
  collection.

  Examples:

  ```DataWeave
  #[MunitTools::isEmpty()]
  ```

- [hasKey(Matcher)](https://docs.mulesoft.com/munit/latest/iterable-map-matchers-reference#haskey-matcher) checks that the expression has a
  key that matches the specified matcher. This matcher works only for maps.

  Examples:

  ```DataWeave
  #[MunitTools::hasKey(MunitTools::equalTo('myKey'))]
  ```

  ```DataWeave
  #[MunitTools::hasKey(MunitTools::startsWith('a'))]
  ```

- [hasValue(Matcher)](https://docs.mulesoft.com/munit/latest/iterable-map-matchers-reference#hasvalue-matcher) checks that the expression
  has a value that matches the specified matcher. This matcher works only for maps.

  Examples:

  ```DataWeave
  #[MunitTools::hasValue(MunitTools::equalTo('myValue'))]
  ```

  ```DataWeave
  #[MunitTools::hasValue(MunitTools::startsWith('a'))]
  ```

## See Also

- [Core Matchers Reference](https://docs.mulesoft.com/munit/latest/core-matchers-reference)

- [String Matchers Reference](https://docs.mulesoft.com/munit/latest/string-matchers-reference)

- [Iterable and Map Matchers Reference](https://docs.mulesoft.com/munit/latest/iterable-map-matchers-reference)

- [Assert That Event Processor](https://docs.mulesoft.com/munit/latest/assertion-event-processor)

<!-- document id=cdc6b27fe5319730067b7cf073a537cb741acc7e59d92b340be43c90c470528b url=/mulesoft/current/en-us/munit/2.3/munit-maven-plugin.md -->

---
product: MUnit
version: 2.3
keywords: munit, testing, unit testing
---

# MUnit Maven Plugin

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

MUnit provides a Maven plugin that enables you to run your MUnit tests as part of your continuous
integration environment.

The following configurations to the `pom.xml` or `settings.xml` files of your Maven installation
apply only when running Munit through Maven.

## Set Up MUnit Maven Plugin

This documentation assumes you have the `<munit.version>` property in your pom.xml.

- Enable the MUnit Maven plugin in your `pom.xml` file:

  MUnit Maven Plugin

  ```xml
  <build>
    <plugins>
    ...

      <plugin>
        <groupId>com.mulesoft.munit.tools</groupId>
        <artifactId>munit-maven-plugin</artifactId>
        <version>${munit.version}</version>
        <executions>
          <execution>
            <id>test</id>
            <phase>test</phase>
            <goals>
              <goal>test</goal>
            </goals>
          </execution>
        </executions>
      </plugin>

    ...
    </plugins>
  </build>
  ```

- Add MUnit dependencies to your `pom.xml` file:

  Dependencies

  ```xml
  <dependencies>
    ...
    <dependency>
      <groupId>com.mulesoft.munit</groupId>
      <artifactId>munit-runner</artifactId>
      <version>${munit.version}</version>
      <classifier>mule-plugin</classifier>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>com.mulesoft.munit</groupId>
      <artifactId>munit-tools</artifactId>
      <version>${munit.version}</version>
      <classifier>mule-plugin</classifier>
      <scope>test</scope>
    </dependency>
    ...
  </dependencies>
  ```

- Configure the repositories for the MUnit dependencies and plugin:

  Repositories

  ```xml
  <repositories>
    <repository>
      <id>mulesoft-releases</id>
        <name>MuleSoft Releases Repository</name>
        <url>https://repository.mulesoft.org/releases/</url>
        <layout>default</layout>
      </repository>
  </repositories>
  ```

  Plugin Repositories

  ```xml
  <pluginRepositories>
    <pluginRepository>
      <id>mulesoft-release</id>
      <name>mulesoft release repository</name>
      <layout>default</layout>
      <url>https://repository.mulesoft.org/releases/</url>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
    </pluginRepository>
  </pluginRepositories>
  ```

MUnit has Surefire support built in. The reports output to `target/surefire-reports`.

### Handle Parent POM Files

You can declare the MUnit plugin in a parent `pom.xml` file and every child project under this file
can reference this definition.

To configure the MUnit Maven plugin in a parent-child POM relationship, include the MUnit plugin
declaration in the `<pluginManagement>` section of your parent `pom.xml` file.

In the following example, the `pirate-pom` project declares the MUnit Maven plugin in its plugin
management section, which defines a global configuration that each child under this parent can
reference, override or even ignore.

```xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.1.0</modelVersion>

    <groupId>org.pirate</groupId>
    <artifactId>pirate-pom</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>pom</packaging>

    <properties>
        <munit.version>2.3.0</munit.version>
    </properties>

    <build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>com.mulesoft.munit.tools</groupId>
                    <artifactId>munit-maven-plugin</artifactId>
                    <version>${munit.version}</version>
                    <executions>
                        <execution>
                            <id>test</id>
                            <phase>test</phase>
                            <goals>
                                <goal>test</goal>
                            </goals>
                        </execution>
                    </executions>
                    <configuration>
                      <coverage>
                          <runCoverage>true</runCoverage>
                          <failBuild>false</failBuild>
                          <requiredApplicationCoverage>0</requiredApplicationCoverage>
                          <requiredResourceCoverage>0</requiredResourceCoverage>
                          <requiredFlowCoverage>0</requiredFlowCoverage>
                          <formats>
                              <format>console</format>
                              <format>html</format>
                          </formats>
                      </coverage>
                    </configuration>
                </plugin>
            </plugins>
        </pluginManagement>
    </build>
</project>
```

### Inherit a Parent Plugin

To inherit the MUnit plugin in your child `pom.xml` files, reference it in the `<plugin>` section of
each child POM file individually.

The following sample references `pirate-pom` file as its parent and then declares the MUnit plugin
in a `<plugin>` section without specifying its `<version>` because the MUnit plugin configuration is
inherited from the `<pluginManagement>` section in the parent POM file:

POM child file sample

```xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

    <parent>
        <groupId>org.pirate</groupId>
        <artifactId>pirate-pom</artifactId>
        <version>1.0-SNAPSHOT</version>
    </parent>

    <modelVersion>4.0.0</modelVersion>
    <groupId>com.mycompany</groupId>
    <artifactId>ninja</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>mule</packaging>
    <name>Mule ninja Application</name>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <app.runtime>4.1.4</app.runtime>
        <munit.version>2.3.0</munit.version>
    </properties>

    <build>
        <plugins>
            <plugin>
                <groupId>com.mulesoft.munit.tools</groupId>
                <artifactId>munit-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>
</project>
```

### Ignore a Parent Plugin

Each child project under a parent `pom.xml` file can ignore the plugin referenced in the parent
plugin management section and not implement the plugin configuration declared there.

By not declaring the Munit Plugin in your `<plugin>` section, you avoid inheriting the plugin
declared in **pirate-pom**:

Child POM file not inheriting the MUnit Maven Plugin

```xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

    <parent>
        <groupId>org.pirate</groupId>
        <artifactId>pirate-pom</artifactId>
        <version>1.0-SNAPSHOT</version>
    </parent>

    <modelVersion>4.0.0</modelVersion>
    <groupId>com.mycompany</groupId>
    <artifactId>ninja</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>mule</packaging>
    <name>Mule ninja Application</name>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <mule.version>4.1.0</mule.version>
        <munit.version>2.3.0</munit.version>
    </properties>

    <build>
        <plugins>
            <plugin>
            </plugin>
        </plugins>
    </build>
</project>
```

### Override a Parent Plugin

When inheriting the plugin from a parent POM file, you can also override the parent configuration.
Overriding the plugin configuration from your parent POM file suppresses the original configuration
requiring you to declare all necessary configurations again.

The following example overrides the console coverage report from its parent POM file, replacing it
by the HTML report. Because the values from the other elements in the parent (`<failBuild>`,
`<requiredApplicationCoverage>`, `<requiredResourceCoverage>`, `<requiredFlowCoverage>`) are not
being referenced, this child file won’t inherit them and the default values will apply:

Coverage configuration in parent POM file

```xml
<coverage>
	<runCoverage>true</runCoverage>
	<failBuild>false</failBuild>
	<requiredApplicationCoverage>0</requiredApplicationCoverage>
	<requiredResourceCoverage>0</requiredResourceCoverage>
	<requiredFlowCoverage>0</requiredFlowCoverage>
	<formats>
		<format>console</format>
		<format>html</format>
	</formats>
</coverage>
```

POM child file overriding coverage report’s format

```xml
<plugin>
	<groupId>com.mulesoft.munit.tools</groupId>
	<artifactId>munit-maven-plugin</artifactId>
	<configuration>
		<coverage>
			<runCoverage>true</runCoverage>
			<formats>
				<format>html</format>
			</formats>
		</coverage>
	</configuration>
</plugin>
```

## Set Up Coverage

The following configurations only apply when you execute your MUnit tests using the Maven plugin.
They do not apply when running tests from Studio. See
[Using Coverage in Maven](https://docs.mulesoft.com/munit/2.3/coverage-maven-concept) for more information.

Since MUnit 2.x, the coverage report goal is integrated with the maven reporting section. Coverage
Reports are generated during Maven’s `site` lifecycle, during the `coverage-report` goal.

The following configurations apply only when you execute your MUnit tests using the Maven plugin.
They do not apply when running tests from Studio.  
To run coverage reports in Studio see [Using Coverage in Studio](https://docs.mulesoft.com/munit/2.3/coverage-studio-concept).

MUnit Coverage - Sample Maven configuration

```xml
<plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <version>${munit.version}</version>

    <executions>
        <execution>
            <id>test</id>
            <phase>test</phase>
            <goals>
                <goal>test</goal>
                <goal>coverage-report</goal>
            </goals>
        </execution>
    </executions>

    <configuration>
        <coverage>
            <runCoverage>true</runCoverage>
            <failBuild>false</failBuild>

            <requiredApplicationCoverage>75</requiredApplicationCoverage>
            <requiredResourceCoverage>50</requiredResourceCoverage>
            <requiredFlowCoverage>50</requiredFlowCoverage>

            <formats>
                <format>console</format>
                <format>html</format>
            </formats>
        </coverage>
    </configuration>
</plugin>
```

### Set up a Minimum Coverage Level

One of the features of MUnit Coverage is to fail the build if a certain coverage level is not
reached.

MUnit Coverage handles three different levels:

- **Application**: The overall coverage of all your application.

- **Resource**: The coverage level of each individual Mule configuration file.

- **Flow**: The coverage of event processors in each flow.

To define the required coverage levels:

MUnit Coverage - Require Coverage

```xml
<coverage>
    <runCoverage>true</runCoverage>
    <failBuild>true</failBuild>

    <requiredApplicationCoverage>75</requiredApplicationCoverage> (1)
    <requiredResourceCoverage>50</requiredResourceCoverage>
    <requiredFlowCoverage>50</requiredFlowCoverage>
</coverage>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Each value represents a percentage.<br>If a percentage is not defined, it defaults to <strong>-1</strong>, which indicates that no requirements are defined for said level so the build will not fail due to low coverage.</td></tr></tbody></table>

If you define coverage levels but set the property `failBuild` to **false**, and then the levels are
not reached, a warning shows up in the MUnit coverage summary:

```console
===============================================================================
MUnit Coverage Summary
===============================================================================
 * Resources: 2 - Flows: 3 - Processors: 4
 * Application Coverage: 75.00%

----------------------------- WARNING --------------------------------------
 * Flow: file2.xml -> file2Flow1 coverage is below defined limit. Required: 50.0% - Current: 00.00% (1)
====================================================================================
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Warning detailing which coverage level was not met, and where it happened.</td></tr></tbody></table>

### Ignore a flow or a file

Another feature is the ability to ignore either a flow or a file. This way, the ignored resource:

- Does not count as coverage data.

- Does not affect the overall number of message processors.

- Does not cause a build to fail if the flow is not tested or if the flow does not reach coverage
  metrics.

To ignore flows and files:

MUnit Coverage - Ignore both flows and files

```xml
<coverage>
    <runCoverage>true</runCoverage>
    <failBuild>true</failBuild>

    <requiredApplicationCoverage>100</requiredApplicationCoverage>
    <requiredResourceCoverage>100</requiredResourceCoverage>
    <requiredFlowCoverage>100</requiredFlowCoverage>

    <ignoreFlows>
        <ignoreFlow>flow-1</ignoreFlow>
        <ignoreFlow>flow-2</ignoreFlow>
        ...
        <ignoreFlow>flow-n</ignoreFlow>
    </ignoreFlows>

    <ignoreFiles>
        <ignoreFile>mule-config-1.xml</ignoreFile>
        <ignoreFile>mule-config-2.xml</ignoreFile>
        ...
        <ignoreFile>mule-config-n.xml</ignoreFile>
    </ignoreFiles>
</coverage>
```

## Dynamic Ports

MUnit 2.2 and later introduce the `dynamic-port` global element, that allows you to define dynamic
ports at the MUnit suite level. Using this element instead of the plugin configuration described as
follows allows you to set the dynamic port both from Maven and Studio.  
See [Dynamic Ports](https://docs.mulesoft.com/munit/2.3/dynamic-ports) to learn how to configure this element.

When testing a Mule application in a continuous integration (CI) environment, you might encounter
the following scenario:

Your application tries to open a specific port. The port is already in use. The application fails
with a port binding exception.

The MUnit Maven Plugin comes with a built-in feature to make your application use a free port.

MUnit Dynamic Ports instructs the MUnit Maven Plugin to look for unbound ports and reserve them
before running the tests over the Mule application. Each port selected is placed in a system
property under the name indicated in the configuration. The application can acquire the port number
through the use of placeholders afterward.

The Ports to be selected by the plugin are taken from the range: `[40000,50000]`

> [!CAUTION] Dynamic Ports feature is only available as part of the MUnit Maven Plugin. This feature
> does not work when running tests from inside Anypoint Studio.

### Enable Dynamic Ports

To enable the feature, you need to add the following code to the `configuration` section of the
MUnit Maven Plugin:

Dynamic Ports Configuration

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
    ...
    <dynamicPorts>
      <dynamicPort>a.dynamic.port</dynamicPort>
    </dynamicPorts>
    ...
    </configuration>
  </plugin>
</plugins>
```

If you have the `${http.port}` placeholder in your application, the configuration looks something
like:

Example

```xml
<dynamicPorts>
  <dynamicPort>http.port</dynamicPort>
</dynamicPorts>
```

### Prepare Your Application

A placeholder must parameterize the part of the application trying to make use of a port. For
example, to have your Mule application listening for HTTP traffic, provide the following
configuration:

HTTP Application

```xml
<http:listener-config name="HTTP_Listener_config">
  <http:listener-connection host="0.0.0.0" port="8081" />
</http:listener-config>

<flow name="httpFlow">
  <http:listener path="/" config-ref="HTTP_Listener_config"/>
</flow>
```

The previous application always listens in port `8081`. To make it dynamic, change it to:

HTTP Application with dynamic port

```xml
<http:listener-config name="HTTP_Listener_config">
  <http:listener-connection host="0.0.0.0" port="${http.port}"/> (1)
</http:listener-config>

<flow name="httpFlow">
  <http:listener path="/" config-ref="HTTP_Listener_config"/>
</flow>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Notice the placeholder <code>${http.port}</code>.</td></tr></tbody></table>

With the application coded in this way and the configuration of Dynamic Ports in place, your
application starts each run listening on a different port.

## Enable Surefire Reports

MUnit has built-in support for Surefire. No additional configuration is needed, but you can disable
it if you don’t need it:

Disable surefire reports

```none
<enableSurefireReports>false</enableSurefireReports>
```

The reports can be found under `${project.build.directory}/surefire-reports`.

By default, it is set to `true`.

## Enable Sonar Reports

MUnit has built-in support for SonarQube, with a default setting of `true` for `enableSonarReports`.
No additional configuration is needed.

You can find the reports under `${project.build.directory}/sonar-reports`.

You can disable SONAR reports if you don’t need them:

Disable sonar reports

```none
<enableSonarReports>false</enableSonarReports>
```

The reports can be found under `${project.build.directory}/sonar-reports`.

By default, it is set to `true`.

## Run Tests Using the Plugin

### Run MUnit Tests for a Mule Application

Run MUnit tests in a Single Resource Mule project.

```none
mvn clean test
```

### Run a Specific MUnit Test Suite

By using the property `munit.test`, you can instruct the MUnit Maven plugin to run only tests that
belong to a specific test suite:

```maven
mvn clean test -Dmunit.test=<regex-test-suite>
```

This path is relative to `src/test/munit`.

The property `munit.test` accepts regular expressions. The expression is applied to the name of the
MUnit Test Suite file. The regular expression language is the Java implementation.

For example:

```console
mvn clean test -Dmunit.test=.*my-test.*
```

You can leverage this feature by adding naming conventions to your MUnit Test suites.

### Run Specific MUnit Tests

In the same way that you instruct MUnit to run one test suite, you can also configure it to run a
specific test inside that test suite. You must use the property `munit.test` with the addition of
the the special character `#` to append the test name:

```console
mvn clean test -Dmunit.test=<regex-test-suite>#<regex-test-name>
```

It also accepts regular expressions. The expression is applied to the attribute `name` of the MUnit
Test. For example:

```console
mvn clean test -Dmunit.test=.*my-test.*#.*test-scenario-1.*
```

The tests inside the MUnit Test Suite that don’t match the regular expression are flagged as
**ignored**.

You can also configure this from the `pom.xml` configuration:

```xml
<plugins>
  <plugin>
      <groupId>com.mulesoft.munit.tools</groupId>
      <artifactId>munit-maven-plugin</artifactId>
      <configuration>
      ...
      <munitTest>example-MunitTest-suite.xml</munitTest>
      ...
    </configuration>
  </plugin>
</plugins>
```

### Run Tests Using a Specific Tag

You can run only the tests that you grouped under one specific tag:

```console
mvn clean test -Dmunit.tags=<munit-tag>
```

You can also configure this from the `pom.xml` configuration:

```xml
<plugins>
  <plugin>
      <groupId>com.mulesoft.munit.tools</groupId>
      <artifactId>munit-maven-plugin</artifactId>
      <configuration>
      ...
      <munitTags>exampleMunitTag</munitTags>
      ...
    </configuration>
  </plugin>
</plugins>
```

You can specify more than one tag by separating them using a comma.

### Skip All Tests

MUnit leverages the same mechanism as Maven. To skip tests, you must use the `skipTests` parameter:

Skip Tests example

```console
mvn clean package -DskipTests
```

You can also configure this from the `pom.xml` configuration:

```xml
<plugins>
  <plugin>
      <groupId>com.mulesoft.munit.tools</groupId>
      <artifactId>munit-maven-plugin</artifactId>
      <configuration>
      ...
      <skipMunitTests>true</skipMunitTests>
      ...
    </configuration>
  </plugin>
</plugins>
```

### Skip Tests After One Suite Fails

MUnit allows you to skip the rest of the tests if one test suite fails:

```xml
<plugins>
  <plugin>
      <groupId>com.mulesoft.munit.tools</groupId>
      <artifactId>munit-maven-plugin</artifactId>
      <configuration>
      ...
      <skipAfterFailure>true</skipAfterFailure>
      ...
    </configuration>
  </plugin>
</plugins>
```

If not specified, this value is `false` by default.

## Specify The Runtime Product

You can specify the type of runtime in which your applications being tested will run. Accepted
values are:

- `MULE` for community edition.

- `MULE_EE` for enterprise edition.

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <runtimeProduct>MULE</runtimeProduct>
      ...
    </configuration>
  </plugin>
</plugins>
```

### Specify the Runtime Product Version

MUnit allows you to specify the runtime version in which your applications being tested will run.

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <runtimeVersion>4.2.2</runtimeVersion>
      ...
    </configuration>
  </plugin>
</plugins>
```

## Specify The JVM

You can specify the JVM (or the java executable) in which your applications being tested run. You
must populate the `munit.jvm` parameter with the path to the executable:

Specify the JVM

```console
mvn clean package -Dmunit.jvm=/path/to/jdk/bin/java
```

You can also configure this from the `pom.xml` configuration:

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <jvm>/path/to/jdk/bin/java</jvm>
      ...
    </configuration>
  </plugin>
</plugins>
```

### Additional Argument Lines

You can pass additional argument lines to the JVM. Specify each argument in a separate `argLine`:

Argument lines

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <argLines>
          <argLine>-XX:MaxPermSize=512m</argLine>
          <argLine>-Xmx1024m</argLine>
      </argLines>
      ...
    </configuration>
  </plugin>
</plugins>
```

### Environment Variables

To set additional environment variables during the test run, you can specify them with the
respective key and value:

Additional Environment Variables

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <environmentVariables>
        <MY_ENV>exampleValue</MY_ENV>
        <MY_OTHER_ENV>val2</MY_OTHER_ENV>
      </environmentVariables>
      ...
    </configuration>
  </plugin>
</plugins>
```

As shown in the previous example, you can use environment variables to replace placeholders such as
`${MY_ENV}`.

### System Properties Variables

You may need to define specific system variables so that your MUnit test runs successfully:

Setting system property variables

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <systemPropertyVariables>
        <my.property.key>my.property.value</my.property.key>
      </systemPropertyVariables>
      ...
    </configuration>
  </plugin>
</plugins>
```

Depending on the execution context, the system properties values may vary. When referencing these
properties, it is a good practice to override their value to enforce test reproducibility.

You can do so using the ­`-D` argument when running MUnit with Maven. Variables passed with the `-D`
argument take full priority over any other property. For example:

```none
-Dmy.property.key=my.property.another.value
```

## Redirect Test Output to File

When running several tests, the build output can get very complex to read. MUnit allows you to
redirect the output of each test suite to a file. This way, only the test results will remain in the
build output and to you can check the respective file to check the standard output of each test
suite.

These files are located in the `testOutputDirectory` folder following the naming convention:
`munit.${suiteName}-output.txt`, where the `suiteName` represents the name of the XML file relative
to the MUnit test folder.

The test’s output that doesn’t belong to a particular suite won’t be printed to keep the build
output clean, but it can be enabled by running maven in debug mode.

To redirect the output of each test suite to a file:

Redirect test output to file

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <redirectTestOutputToFile>true</redirectTestOutputToFile>
      ...
    </configuration>
  </plugin>
</plugins>
```

By default, it is set to `false`

### Test Output Directory

You may want to choose the location where the test output files will be created. The path specified
can be absolute or written as a Maven placeholder:

Test output directory with absolute path

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <testOutputDirectory>/my/absolute/path</testOutputDirectory>
      ...
    </configuration>
  </plugin>
</plugins>
```

Test output directory using maven placeholders

```xml
<testOutputDirectory>${project.build.directory}/my/output/folder</testOutputDirectory>
```

By default, the files are created in `${project.build.directory}/munit-reports/output/`.

## MUnit Maven Plugin Configuration Reference

The MUnit Maven Plugin offers a set of optional parameters that can be configured.

<table><caption>Table 1. Maven Plugin Parameters</caption> <colgroup><col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><code>argLines</code></p></div></div></td><td><div><div><p>List</p></div></div></td><td><div><div><p>Additional JVM argument lines to set on the test run.</p></div></div></td></tr><tr><td><div><div><p><code>coverage</code></p></div></div></td><td><div><div><p>Configuration</p></div></div></td><td><div><div><p>Coverage configuration to be set on the test run.</p></div></div></td></tr><tr><td><div><div><p><code>dynamicPorts</code></p></div></div></td><td><div><div><p>List</p></div></div></td><td><div><div><p>Dynamic ports to be set on the test run.</p></div></div></td></tr><tr><td><div><div><p><code>enableSurefireReports</code></p></div></div></td><td><div><div><p>boolean</p></div></div></td><td><div><div><p>Set value to <code>true</code> to generate MUnit test results in the surefire format.<br>Default value: <code>true</code></p></div></div></td></tr><tr><td><div><div><p><code>munitTest</code></p></div></div></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the MUnit tests to run.</p></div></div></td></tr><tr><td><div><div><p><code>munitTags</code></p></div></div></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the MUnit tags. Only tests tagged with these names will run.</p></div></div></td></tr><tr><td><div><div><p><code>skipMunitTests</code></p></div></div></td><td><div><div><p>boolean</p></div></div></td><td><div><div><p>Set to <code>true</code> when you want to skip all MUnit tests.<br>Default value: <code>false</code></p></div></div></td></tr><tr><td><div><div><p><code>skipAfterFailure</code></p></div></div></td><td><div><div><p>boolean</p></div></div></td><td><div><div><p>Skip all tests if one fails.<br>Default value: <code>false</code></p></div></div></td></tr><tr><td><div><div><p><code>munitTestsDirectory</code></p></div></div></td><td><div><div><p>File</p></div></div></td><td><div><div><p>Directory where the MUnit tests reside.<br>Default value: <code>${project.build.directory}/test-mule/munit</code></p></div></div></td></tr><tr><td><div><div><p><code>runtimeVersion</code></p></div></div></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Version of the Mule runtime<br>When you run your tests from Maven, this value is taken from the <code>minMuleVersion</code> parameter in the <code>mule-artifact.json</code> file.<br>To modify the Mule runtime version used to run your MUnit tests in Studio, see <a href="https://docs.mulesoft.com/munit/2.3/runtime-patching#studio">Runtime Patching in Studio</a>.</p></div></div></td></tr><tr><td><div><div><p>runtimeProduct</p></div></div></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Type of runtime. Expected values are:</p></div><div><ul><li><p><code>MULE</code> for community edition</p></li><li><p><code>MULE_EE</code> for enterprise edition.</p></li></ul></div><div><p>By default, this value is taken from the <code>requiredProduct</code> parameter in the <code>mule-artifact.json</code> file.</p></div></div></td></tr><tr><td><div><div><p><code>jvm</code></p></div></div></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Option to specify the JVM (or path to the java executable) to use.</p></div><div><p>By default, the JVM will the same VM as the one used to run Maven.</p></div></div></td></tr><tr><td><div><div><p><code>environmentVariables</code></p></div></div></td><td><div><div><p>Map</p></div></div></td><td><div><div><p>Additional environment variables to be set on the test run.</p></div></div></td></tr><tr><td><div><div><p><code>redirectTestOutputToFile</code></p></div></div></td><td><div><div><p>boolean</p></div></div></td><td><div><div><p>Set value to <code>true</code> to redirect the MUnit tests standard output to a file.<br>Default value: <code>false</code></p></div></div></td></tr><tr><td><div><div><p><code>systemPropertyVariables</code></p></div></div></td><td><div><div><p>Map</p></div></div></td><td><div><div><p>System properties to be set on the test run.</p></div></div></td></tr><tr><td><div><div><p><code>testOutputDirectory</code></p></div></div></td><td><div><div><p>File</p></div></div></td><td><div><div><p>Directory where the test outputs will be written to.<br>Default value: <code>${project.build.directory}/munit-reports/output/</code></p></div></div></td></tr></tbody></table>

<!-- document id=d7dba393cd744e564be1acdd2e2aae35a7b731fa73e450517ec64fc05db8ebaf url=/mulesoft/current/en-us/munit/3.6/munit-maven-plugin.md -->

---
product: MUnit
version: 3.6
keywords: munit, testing, unit testing
---

# MUnit Maven Plugin

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

MUnit provides a Maven plugin that enables you to run your MUnit tests as part of your continuous
integration environment.

The following configurations to the `pom.xml` or `settings.xml` files of your Maven installation
apply only when running MUnit through Maven.

## Set Up MUnit Maven Plugin

You must have the `<munit.version>` property in your pom.xml to set up MUnit Maven Plugin.

- Enable MUnit Maven Plugin in your `pom.xml` file:

  MUnit Maven Plugin

  ```xml
  <build>
    <plugins>
    ...

      <plugin>
        <groupId>com.mulesoft.munit.tools</groupId>
        <artifactId>munit-maven-plugin</artifactId>
        <version>${munit.version}</version>
        <executions>
          <execution>
            <id>test</id>
            <phase>test</phase>
            <goals>
              <goal>test</goal>
            </goals>
          </execution>
        </executions>
      </plugin>

    ...
    </plugins>
  </build>
  ```

- Add MUnit dependencies to your `pom.xml` file:

  Dependencies

  ```xml
  <dependencies>
    ...
    <dependency>
      <groupId>com.mulesoft.munit</groupId>
      <artifactId>munit-runner</artifactId>
      <version>${munit.version}</version>
      <classifier>mule-plugin</classifier>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>com.mulesoft.munit</groupId>
      <artifactId>munit-tools</artifactId>
      <version>${munit.version}</version>
      <classifier>mule-plugin</classifier>
      <scope>test</scope>
    </dependency>
    ...
  </dependencies>
  ```

- Configure the repositories for the MUnit dependencies and plugin:

  Repositories

  ```xml
  <repositories>
    <repository>
      <id>mulesoft-releases</id>
        <name>MuleSoft Releases Repository</name>
        <url>https://repository.mulesoft.org/releases/</url>
        <layout>default</layout>
      </repository>
  </repositories>
  ```

  Plugin Repositories

  ```xml
  <pluginRepositories>
    <pluginRepository>
      <id>mulesoft-release</id>
      <name>mulesoft release repository</name>
      <layout>default</layout>
      <url>https://repository.mulesoft.org/releases/</url>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
    </pluginRepository>
  </pluginRepositories>
  ```

> [!NOTE] MUnit has Surefire support built in. The reports output to `target/surefire-reports`.

### Handle Parent POM Files

You can declare the MUnit plugin in a parent `pom.xml` file and every child project under this file
can reference this definition.

To configure MUnit Maven Plugin in a parent-child POM relationship, include the MUnit plugin
declaration in the `<pluginManagement>` section of your parent `pom.xml` file.

In the following example, the `pirate-pom` project declares MUnit Maven Plugin in its plugin
management section. This section also defines a global configuration that each child under this
parent can reference, override, or ignore.

```xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.1.0</modelVersion>

    <groupId>org.pirate</groupId>
    <artifactId>pirate-pom</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>pom</packaging>

    <properties>
        <munit.version>2.3.0</munit.version>
    </properties>

    <build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>com.mulesoft.munit.tools</groupId>
                    <artifactId>munit-maven-plugin</artifactId>
                    <version>${munit.version}</version>
                    <executions>
                        <execution>
                            <id>test</id>
                            <phase>test</phase>
                            <goals>
                                <goal>test</goal>
                            </goals>
                        </execution>
                    </executions>
                    <configuration>
                      <coverage>
                          <runCoverage>true</runCoverage>
                          <failBuild>false</failBuild>
                          <requiredApplicationCoverage>0</requiredApplicationCoverage>
                          <requiredResourceCoverage>0</requiredResourceCoverage>
                          <requiredFlowCoverage>0</requiredFlowCoverage>
                          <formats>
                              <format>console</format>
                              <format>html</format>
                          </formats>
                      </coverage>
                    </configuration>
                </plugin>
            </plugins>
        </pluginManagement>
    </build>
</project>
```

### Inherit a Parent Plugin

To inherit the MUnit plugin in your child `pom.xml` files, reference it in the `<plugin>` section of
each child POM file individually.

The following sample references the `pirate-pom` file as its parent. It declares the MUnit plugin in
a `<plugin>` section without specifying its `<version>` because the MUnit plugin configuration is
inherited from the `<pluginManagement>` section in the parent POM file:

POM child file sample

```xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

    <parent>
        <groupId>org.pirate</groupId>
        <artifactId>pirate-pom</artifactId>
        <version>1.0-SNAPSHOT</version>
    </parent>

    <modelVersion>4.0.0</modelVersion>
    <groupId>com.mycompany</groupId>
    <artifactId>ninja</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>mule</packaging>
    <name>Mule ninja Application</name>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <app.runtime>4.1.4</app.runtime>
        <munit.version>2.3.0</munit.version>
    </properties>

    <build>
        <plugins>
            <plugin>
                <groupId>com.mulesoft.munit.tools</groupId>
                <artifactId>munit-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>
</project>
```

### Ignore a Parent Plugin

Each child project under a parent `pom.xml` file can ignore the plugin referenced in the parent
plugin management section and not implement the plugin configuration declared there.

By not declaring the MUnit Plugin in your `<plugin>` section, you avoid inheriting the plugin
declared in **pirate-pom**:

Child POM file not inheriting the MUnit Maven Plugin

```xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

    <parent>
        <groupId>org.pirate</groupId>
        <artifactId>pirate-pom</artifactId>
        <version>1.0-SNAPSHOT</version>
    </parent>

    <modelVersion>4.0.0</modelVersion>
    <groupId>com.mycompany</groupId>
    <artifactId>ninja</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>mule</packaging>
    <name>Mule ninja Application</name>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <mule.version>4.1.0</mule.version>
        <munit.version>2.3.0</munit.version>
    </properties>

    <build>
        <plugins>
            <plugin>
            </plugin>
        </plugins>
    </build>
</project>
```

### Override a Parent Plugin

When inheriting the plugin from a parent POM file, you can also override the parent configuration.
Overriding the plugin configuration from your parent POM file suppresses the original configuration
requiring you to declare all necessary configurations again.

The following example overrides the console coverage report from its parent POM file, replacing it
with the HTML report. Because the values from the other elements in the parent (`<failBuild>`,
`<requiredApplicationCoverage>`, `<requiredResourceCoverage>`, `<requiredFlowCoverage>`) aren’t
being referenced, this child file won’t inherit them and the default values are applied:

Coverage configuration in parent POM file

```xml
<coverage>
	<runCoverage>true</runCoverage>
	<failBuild>false</failBuild>
	<requiredApplicationCoverage>0</requiredApplicationCoverage>
	<requiredResourceCoverage>0</requiredResourceCoverage>
	<requiredFlowCoverage>0</requiredFlowCoverage>
	<formats>
		<format>console</format>
		<format>html</format>
	</formats>
</coverage>
```

POM child file overriding coverage report format

```xml
<plugin>
	<groupId>com.mulesoft.munit.tools</groupId>
	<artifactId>munit-maven-plugin</artifactId>
	<configuration>
		<coverage>
			<runCoverage>true</runCoverage>
			<formats>
				<format>html</format>
			</formats>
		</coverage>
	</configuration>
</plugin>
```

## Set Up Coverage

The following configurations only apply when you execute your MUnit tests using the Maven plugin.
They don’t apply when running tests from Studio. See
[Using Coverage in Maven](https://docs.mulesoft.com/munit/3.6/coverage-maven-concept) for additional information.

From MUnit 2.x and later, the coverage report goal is integrated with the Maven reporting section.
MUnit generates coverage reports during the Maven `site` lifecycle, during the `coverage-report`
goal.

The following configurations apply if you execute your MUnit tests using the Maven plugin. They
don’t apply when running tests from Anypoint Code Builder or Anypoint Studio.

MUnit Coverage - Sample Maven configuration

```xml
<plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <version>${munit.version}</version>

    <executions>
        <execution>
            <id>test</id>
            <phase>test</phase>
            <goals>
                <goal>test</goal>
                <goal>coverage-report</goal>
            </goals>
        </execution>
    </executions>

    <configuration>
        <coverage>
            <runCoverage>true</runCoverage>
            <failBuild>false</failBuild>

            <requiredApplicationCoverage>75</requiredApplicationCoverage>
            <requiredResourceCoverage>50</requiredResourceCoverage>
            <requiredFlowCoverage>50</requiredFlowCoverage>

            <formats>
                <format>console</format>
                <format>html</format>
            </formats>
        </coverage>
    </configuration>
</plugin>
```

### Set up a Minimum Coverage Level

One of the features of MUnit Coverage is to fail the build if a certain coverage level isn’t
reached.

MUnit Coverage handles three different levels:

- **Application**: The overall coverage of all your application.

- **Resource**: The coverage level of each Mule configuration file.

- **Flow**: The coverage of event processors in each flow.

To define the required coverage levels:

MUnit Coverage - Require Coverage

```xml
<coverage>
    <runCoverage>true</runCoverage>
    <failBuild>true</failBuild>

    <requiredApplicationCoverage>75</requiredApplicationCoverage> (1)
    <requiredResourceCoverage>50</requiredResourceCoverage>
    <requiredFlowCoverage>50</requiredFlowCoverage>
</coverage>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Each value represents a percentage.<br>If a percentage isn’t defined, it defaults to <strong>-1</strong>, which sets no requirements for said level so the build doesn’t fail due to low coverage.</td></tr></tbody></table>

If you define coverage levels but set the property `failBuild` to `false`, and then the levels
aren’t reached, a warning shows up in the MUnit Coverage summary:

```console
===============================================================================
MUnit Coverage Summary
===============================================================================
 * Resources: 2 - Flows: 3 - Processors: 4
 * Application Coverage: 75.00%

----------------------------- WARNING --------------------------------------
 * Flow: file2.xml -> file2Flow1 coverage is below defined limit. Required: 50.0% - Current: 00.00% (1)
====================================================================================
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Warning detailing which coverage level isn’t met, and where it happens.</td></tr></tbody></table>

### Ignore a Flow or a File

You can also ignore a flow or a file. This way, the ignored resource:

- Does not count as coverage data.

- Does not affect the overall number of message processors.

- Does not cause a build to fail if the flow isn’t tested or if the flow doesn’t reach coverage
  metrics.

To ignore flows and files:

MUnit Coverage - Ignore flows and files

```xml
<coverage>
    <runCoverage>true</runCoverage>
    <failBuild>true</failBuild>

    <requiredApplicationCoverage>100</requiredApplicationCoverage>
    <requiredResourceCoverage>100</requiredResourceCoverage>
    <requiredFlowCoverage>100</requiredFlowCoverage>

    <ignoreFlows>
        <ignoreFlow>flow-1</ignoreFlow>
        <ignoreFlow>flow-2</ignoreFlow>
        ...
        <ignoreFlow>flow-n</ignoreFlow>
    </ignoreFlows>

    <ignoreFiles>
        <ignoreFile>mule-config-1.xml</ignoreFile>
        <ignoreFile>mule-config-2.xml</ignoreFile>
        ...
        <ignoreFile>mule-config-n.xml</ignoreFile>
    </ignoreFiles>
</coverage>
```

## Dynamic Ports

MUnit 2.2 and later introduce the `dynamic-port` global element, that allows you to define dynamic
ports at the MUnit suite level. Using this element instead of the plugin configuration described as
follows allows you to set the dynamic port both from Maven and Studio.  
See [Dynamic Ports](https://docs.mulesoft.com/munit/3.6/dynamic-ports) to learn how to configure this element.

When testing a Mule application in a continuous integration (CI) environment, you might encounter
the following scenario:

Your application tries to open a specific port. The port is already in use. The application fails
with a port binding exception.

The MUnit Maven Plugin comes with a built-in feature to make your application use a free port.

MUnit Dynamic Ports instructs the MUnit Maven Plugin to look for unbound ports and reserve them
before running the tests over the Mule application. Each port selected is placed in a system
property under the name indicated in the configuration. The application can get the port number
through the use of placeholders afterward.

The plugin selects the ports from the range: `[40000,50000]`

> [!CAUTION] Dynamic Ports feature is only available as part of the MUnit Maven Plugin. This feature
> does not work when running tests in Anypoint Studio.

### Enable Dynamic Ports

To enable the feature, you must add the following code to the `configuration` section of the MUnit
Maven Plugin:

Dynamic Ports Configuration

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
    ...
    <dynamicPorts>
      <dynamicPort>a.dynamic.port</dynamicPort>
    </dynamicPorts>
    ...
    </configuration>
  </plugin>
</plugins>
```

If you have the `${http.port}` placeholder in your application, the configuration looks something
like:

Example

```xml
<dynamicPorts>
  <dynamicPort>http.port</dynamicPort>
</dynamicPorts>
```

### Prepare Your Application

A placeholder must parameterize the part of the application trying to make use of a port. For
example, to have your Mule application listening for HTTP traffic, provide the following
configuration:

HTTP Application

```xml
<http:listener-config name="HTTP_Listener_config">
  <http:listener-connection host="0.0.0.0" port="8081" />
</http:listener-config>

<flow name="httpFlow">
  <http:listener path="/" config-ref="HTTP_Listener_config"/>
</flow>
```

The previous application always listens in port `8081`. To make it dynamic, change it to:

HTTP Application with dynamic port

```xml
<http:listener-config name="HTTP_Listener_config">
  <http:listener-connection host="0.0.0.0" port="${http.port}"/> (1)
</http:listener-config>

<flow name="httpFlow">
  <http:listener path="/" config-ref="HTTP_Listener_config"/>
</flow>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Notice the placeholder <code>${http.port}</code>.</td></tr></tbody></table>

With the application coded in this way and the configuration of Dynamic Ports in place, your
application starts each run listening on a different port.

## Enable Surefire Reports

MUnit has built-in support for Surefire. You mustn’t do additional configurations, and you can
disable it if not needed:

Disable Surefire reports

```none
<enableSurefireReports>false</enableSurefireReports>
```

You can find the reports under `${project.build.directory}/surefire-reports`.

By default, it’s set to `true`.

## Enable Sonar Reports

MUnit has built-in support for SonarQube, with a default setting of `true` for `enableSonarReports`.
No other configuration is required.

You can find the reports under `${project.build.directory}/sonar-reports`.

You can disable SONAR reports if not needed:

Disable Sonar reports

```none
<enableSonarReports>false</enableSonarReports>
```

You can find the reports under `${project.build.directory}/sonar-reports`.

By default, it’s set to `true`.

## Run Tests Using the Plugin

### Run MUnit Tests for a Mule Application

Run MUnit tests in a Single Resource Mule project.

```none
mvn clean test
```

### Run a Specific MUnit Test Suite

By using the property `munit.test`, you can instruct the MUnit Maven plugin to run certain tests
that belong to a specific test suite:

```maven
mvn clean test -Dmunit.test=<regex-test-suite>
```

This path is relative to `src/test/munit`.

The property `munit.test` accepts regular expressions. The expression is applied to the name of the
MUnit Test Suite file. The regular expression language is the Java implementation.

For example:

```console
mvn clean test -Dmunit.test=.*my-test.*
```

You can leverage this feature by adding naming conventions to your MUnit Test suites.

### Run Specific MUnit Tests

In the same way that you instruct MUnit to run one test suite, you can also configure it to run a
specific test in that test suite. You must use the property `munit.test` with the addition of the
special character `#` to append the test name:

```console
mvn clean test -Dmunit.test=<regex-test-suite>#<regex-test-name>
```

It also accepts regular expressions. The expression is applied to the attribute `name` of the MUnit
Test. For example:

```console
mvn clean test -Dmunit.test=.*my-test.*#.*test-scenario-1.*
```

MUnit flags the tests in the MUnit Test Suite that don’t match the regular expression as
**ignored**.

You can also configure this from the `pom.xml` configuration:

```xml
<plugins>
  <plugin>
      <groupId>com.mulesoft.munit.tools</groupId>
      <artifactId>munit-maven-plugin</artifactId>
      <configuration>
      ...
      <munitTest>example-MunitTest-suite.xml</munitTest>
      ...
    </configuration>
  </plugin>
</plugins>
```

### Run Tests Using a Specific Tag

You can run the tests that you grouped under one specific tag:

```console
mvn clean test -Dmunit.tags=<munit-tag>
```

You can also configure this from the `pom.xml` configuration:

```xml
<plugins>
  <plugin>
      <groupId>com.mulesoft.munit.tools</groupId>
      <artifactId>munit-maven-plugin</artifactId>
      <configuration>
      ...
      <munitTags>exampleMunitTag</munitTags>
      ...
    </configuration>
  </plugin>
</plugins>
```

You can specify more than one tag by separating them with a comma.

### Skip All Tests

MUnit leverages the same mechanism as Maven. To skip tests, you must use the `skipTests` parameter:

Skip Tests example

```console
mvn clean package -DskipTests
```

You can also configure this from the `pom.xml` configuration:

```xml
<plugins>
  <plugin>
      <groupId>com.mulesoft.munit.tools</groupId>
      <artifactId>munit-maven-plugin</artifactId>
      <configuration>
      ...
      <skipMunitTests>true</skipMunitTests>
      ...
    </configuration>
  </plugin>
</plugins>
```

### Skip Tests After One Suite Fails

MUnit allows you to skip the rest of the tests if one test suite fails:

```xml
<plugins>
  <plugin>
      <groupId>com.mulesoft.munit.tools</groupId>
      <artifactId>munit-maven-plugin</artifactId>
      <configuration>
      ...
      <skipAfterFailure>true</skipAfterFailure>
      ...
    </configuration>
  </plugin>
</plugins>
```

If not specified, it’s default value is `false`.

## Specify the Runtime Product

You can specify the type of runtime in which the applications you test run. Accepted values are:

- `MULE` for the Mule Kernel (formerly called Mule Community Edition)

- `MULE_EE` for the Mule Enterprise Edition

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <runtimeProduct>MULE</runtimeProduct>
      ...
    </configuration>
  </plugin>
</plugins>
```

### Specify the Runtime Product Version

You can specify the runtime version in which the applications you test run.

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <runtimeVersion>4.2.2</runtimeVersion>
      ...
    </configuration>
  </plugin>
</plugins>
```

## Specify the JVM

You can specify the JVM (or the Java executable) in which the applications you test run. You must
populate the `munit.jvm` parameter with the path to the executable:

Specify the JVM

```console
mvn clean package -Dmunit.jvm=/path/to/jdk/bin/java
```

You can also configure this from the `pom.xml` configuration:

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <jvm>/path/to/jdk/bin/java</jvm>
      ...
    </configuration>
  </plugin>
</plugins>
```

### Additional Argument Lines

You can pass additional argument lines to the JVM. Specify each argument in a separate `argLine`:

Argument lines

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <argLines>
          <argLine>-XX:MaxPermSize=512m</argLine>
          <argLine>-Xmx1024m</argLine>
      </argLines>
      ...
    </configuration>
  </plugin>
</plugins>
```

### Environment Variables

To set additional environment variables during the test run, you can specify them with the
respective key and value:

Additional Environment Variables

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <environmentVariables>
        <MY_ENV>exampleValue</MY_ENV>
        <MY_OTHER_ENV>val2</MY_OTHER_ENV>
      </environmentVariables>
      ...
    </configuration>
  </plugin>
</plugins>
```

As shown in the previous example, you can use environment variables to replace placeholders such as
`${MY_ENV}`.

### System Properties Variables

If you must define specific system variables to run your MUnit test successfully:

Setting system property variables

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <systemPropertyVariables>
        <my.property.key>my.property.value</my.property.key>
      </systemPropertyVariables>
      ...
    </configuration>
  </plugin>
</plugins>
```

Depending on the execution context, the system property values can vary. When referencing these
properties, you must override their value to enforce test reproducibility.

You can do so by using the ­`-D` argument when running MUnit with Maven. Variables passed with the
`-D` argument take full priority over any other property. For example:

```none
-Dmy.property.key=my.property.another.value
```

## Redirect Test Output to File

When running several tests, the build output can get very complex to read. MUnit allows you to
redirect the output of each test suite to a file. This way, the test results remain in the build
output and you can check the respective file to check the standard output of each test suite.

You can find these files in the `testOutputDirectory` folder following the naming convention:
`munit.${suiteName}-output.txt`, where `suiteName` represents the name of the XML file relative to
the MUnit test folder.

The test output that doesn’t belong to a particular suite isn’t printed to keep the build output
clean. You can enable it by running Maven in debug mode.

To redirect the output of each test suite to a file:

Redirect test output to a file

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <redirectTestOutputToFile>true</redirectTestOutputToFile>
      ...
    </configuration>
  </plugin>
</plugins>
```

By default, it’s set to `false`.

### Test Output Directory

If you want to choose the location where the test creates the output files, the path specified can
be absolute or written as a Maven placeholder:

Test output directory with absolute path

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <testOutputDirectory>/my/absolute/path</testOutputDirectory>
      ...
    </configuration>
  </plugin>
</plugins>
```

Test output directory using Maven placeholders

```xml
<testOutputDirectory>${project.build.directory}/my/output/folder</testOutputDirectory>
```

By default, the files are created in `${project.build.directory}/munit-reports/output/`.

## MUnit Maven Plugin Configuration Reference

The MUnit Maven Plugin offers a set of optional configurable parameters.

<table><caption>Table 1. Maven Plugin Parameters</caption> <colgroup><col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><code>argLines</code></p></div></div></td><td><div><div><p>List</p></div></div></td><td><div><div><p>Additional JVM argument lines to set on the test run.</p></div></div></td></tr><tr><td><div><div><p><code>coverage</code></p></div></div></td><td><div><div><p>Configuration</p></div></div></td><td><div><div><p>Coverage configuration to set on the test run.</p></div></div></td></tr><tr><td><div><div><p><code>dynamicPorts</code></p></div></div></td><td><div><div><p>List</p></div></div></td><td><div><div><p>Dynamic ports to set on the test run.</p></div></div></td></tr><tr><td><div><div><p><code>enableSurefireReports</code></p></div></div></td><td><div><div><p>boolean</p></div></div></td><td><div><div><p>Set value to <code>true</code> to generate MUnit test results in the Surefire format.<br>Its default value is <code>true</code>.</p></div></div></td></tr><tr><td><div><div><p><code>munitTest</code></p></div></div></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the MUnit tests to run.</p></div></div></td></tr><tr><td><div><div><p><code>munitTags</code></p></div></div></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the MUnit tags. Tests tagged with these names run.</p></div></div></td></tr><tr><td><div><div><p><code>skipMunitTests</code></p></div></div></td><td><div><div><p>boolean</p></div></div></td><td><div><div><p>Setting this parameter to <code>true</code> skips all MUnit tests.<br>Its default value is <code>false</code>.</p></div></div></td></tr><tr><td><div><div><p><code>skipAfterFailure</code></p></div></div></td><td><div><div><p>boolean</p></div></div></td><td><div><div><p>Skip all tests if one fails.<br>Its default value is <code>false</code>.</p></div></div></td></tr><tr><td><div><div><p><code>munitTestsDirectory</code></p></div></div></td><td><div><div><p>File</p></div></div></td><td><div><div><p>Directory where the MUnit tests reside.<br>Its default value is <code>${project.build.directory}/test-mule/munit</code>.</p></div></div></td></tr><tr><td><div><div><p><code>runtimeVersion</code></p></div></div></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Version of the Mule runtime<br>When you run your tests from Maven, this value comes from the <code>minMuleVersion</code> parameter in the <code>mule-artifact.json</code> file.<br>To modify the Mule runtime version used to run your MUnit tests, see <a href="https://docs.mulesoft.com/munit/3.6/runtime-patching">Runtime Patching</a>.</p></div></div></td></tr><tr><td><div><div><p>runtimeProduct</p></div></div></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Type of runtime. Expected values are:</p></div><div><ul><li><p><code>MULE</code> for the Mule Kernel (formerly called Mule Community Edition)</p></li><li><p><code>MULE_EE</code> for the Mule Enterprise Edition</p></li></ul></div><div><p>By default, this value comes from the <code>requiredProduct</code> parameter in the <code>mule-artifact.json</code> file.</p></div></div></td></tr><tr><td><div><div><p><code>jvm</code></p></div></div></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Option to specify the JVM (or path to the Java executable) to use.</p></div><div><p>By default, the JVM is the same VM as the one used to run Maven.</p></div></div></td></tr><tr><td><div><div><p><code>environmentVariables</code></p></div></div></td><td><div><div><p>Map</p></div></div></td><td><div><div><p>Additional environment variables to set on the test run.</p></div></div></td></tr><tr><td><div><div><p><code>redirectTestOutputToFile</code></p></div></div></td><td><div><div><p>boolean</p></div></div></td><td><div><div><p>Setting this value to <code>true</code> redirects the MUnit tests standard output to a file.<br>Its default value is <code>false</code>.</p></div></div></td></tr><tr><td><div><div><p><code>systemPropertyVariables</code></p></div></div></td><td><div><div><p>Map</p></div></div></td><td><div><div><p>System properties set on the test run.</p></div></div></td></tr><tr><td><div><div><p><code>testOutputDirectory</code></p></div></div></td><td><div><div><p>File</p></div></div></td><td><div><div><p>Directory where the test outputs are written.<br>Its default value is <code>${project.build.directory}/munit-reports/output/</code>.</p></div></div></td></tr></tbody></table>

<!-- document id=c664052e687f080f2edcd7eea1ebcdcccfda182b1aadb2dd913c66b25ee72016 url=/mulesoft/current/en-us/munit/latest/munit-maven-plugin.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
keywords: munit, testing, unit testing
---

# MUnit Maven Plugin

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The MUnit Maven Plugin runs MUnit tests as part of a continuous integration environment by
integrating with the Maven build lifecycle. These configurations apply only when running MUnit
through Maven, not from Anypoint Studio or Anypoint Code Builder.

## Set Up MUnit Maven Plugin

You must have the `<munit.version>` property in your pom.xml to set up MUnit Maven Plugin.

- Enable MUnit Maven Plugin in your `pom.xml` file:

  MUnit Maven Plugin

  ```xml
  <build>
    <plugins>
    ...

      <plugin>
        <groupId>com.mulesoft.munit.tools</groupId>
        <artifactId>munit-maven-plugin</artifactId>
        <version>${munit.version}</version>
        <executions>
          <execution>
            <id>test</id>
            <phase>test</phase>
            <goals>
              <goal>test</goal>
            </goals>
          </execution>
        </executions>
      </plugin>

    ...
    </plugins>
  </build>
  ```

- Add MUnit dependencies to your `pom.xml` file:

  Dependencies

  ```xml
  <dependencies>
    ...
    <dependency>
      <groupId>com.mulesoft.munit</groupId>
      <artifactId>munit-runner</artifactId>
      <version>${munit.version}</version>
      <classifier>mule-plugin</classifier>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>com.mulesoft.munit</groupId>
      <artifactId>munit-tools</artifactId>
      <version>${munit.version}</version>
      <classifier>mule-plugin</classifier>
      <scope>test</scope>
    </dependency>
    ...
  </dependencies>
  ```

- Configure the repositories for the MUnit dependencies and plugin:

  Repositories

  ```xml
  <repositories>
    <repository>
      <id>mulesoft-releases</id>
        <name>MuleSoft Releases Repository</name>
        <url>https://repository.mulesoft.org/releases/</url>
        <layout>default</layout>
      </repository>
  </repositories>
  ```

  Plugin Repositories

  ```xml
  <pluginRepositories>
    <pluginRepository>
      <id>mulesoft-release</id>
      <name>mulesoft release repository</name>
      <layout>default</layout>
      <url>https://repository.mulesoft.org/releases/</url>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
    </pluginRepository>
  </pluginRepositories>
  ```

Most applications require Mule runtime engine Enterprise Edition to run MUnit tests. Maven downloads
the Enterprise runtime from a plugin repository.

1.  Configure your Enterprise repository credentials. See
    [Configure MuleSoft Enterprise Repository](https://docs.mulesoft.com/mule-runtime/latest/maven-reference#configure-mulesoft-enterprise-repository).

2.  Add the Enterprise repository as a plugin repository in the `pluginRepositories` section of your
    `pom.xml` file, together with the MuleSoft releases plugin repository. Set `id` to the same
    value as the `<id>` in the `<server>` entry of your `settings.xml` file:

    Enterprise Plugin Repository

    ```xml
    <pluginRepositories>
      ...
      <pluginRepository>
        <id>MuleRepository</id>
        <name>MuleRepository</name>
        <url>https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/</url>
        <layout>default</layout>
        <releases>
          <enabled>true</enabled>
        </releases>
        <snapshots>
          <enabled>true</enabled>
        </snapshots>
      </pluginRepository>
    </pluginRepositories>
    ```

> [!NOTE] MUnit has Surefire support built in. The reports output to `target/surefire-reports`.

### Handle Parent POM Files

You can declare the MUnit plugin in a parent `pom.xml` file and every child project under this file
can reference this definition.

To configure MUnit Maven Plugin in a parent-child POM relationship, include the MUnit plugin
declaration in the `<pluginManagement>` section of your parent `pom.xml` file.

In the following example, the `pirate-pom` project declares MUnit Maven Plugin in its plugin
management section. This section also defines a global configuration that each child under this
parent can reference, override, or ignore.

```xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.1.0</modelVersion>

    <groupId>org.pirate</groupId>
    <artifactId>pirate-pom</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>pom</packaging>

    <properties>
        <munit.version>2.3.0</munit.version>
    </properties>

    <build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>com.mulesoft.munit.tools</groupId>
                    <artifactId>munit-maven-plugin</artifactId>
                    <version>${munit.version}</version>
                    <executions>
                        <execution>
                            <id>test</id>
                            <phase>test</phase>
                            <goals>
                                <goal>test</goal>
                            </goals>
                        </execution>
                    </executions>
                    <configuration>
                      <coverage>
                          <runCoverage>true</runCoverage>
                          <failBuild>false</failBuild>
                          <requiredApplicationCoverage>0</requiredApplicationCoverage>
                          <requiredResourceCoverage>0</requiredResourceCoverage>
                          <requiredFlowCoverage>0</requiredFlowCoverage>
                          <formats>
                              <format>console</format>
                              <format>html</format>
                          </formats>
                      </coverage>
                    </configuration>
                </plugin>
            </plugins>
        </pluginManagement>
    </build>
</project>
```

### Inherit a Parent Plugin

To inherit the MUnit plugin in your child `pom.xml` files, reference it in the `<plugin>` section of
each child POM file individually.

The following sample references the `pirate-pom` file as its parent. It declares the MUnit plugin in
a `<plugin>` section without specifying its `<version>` because the MUnit plugin configuration is
inherited from the `<pluginManagement>` section in the parent POM file:

POM child file sample

```xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

    <parent>
        <groupId>org.pirate</groupId>
        <artifactId>pirate-pom</artifactId>
        <version>1.0-SNAPSHOT</version>
    </parent>

    <modelVersion>4.0.0</modelVersion>
    <groupId>com.mycompany</groupId>
    <artifactId>ninja</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>mule</packaging>
    <name>Mule ninja Application</name>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <app.runtime>4.1.4</app.runtime>
        <munit.version>2.3.0</munit.version>
    </properties>

    <build>
        <plugins>
            <plugin>
                <groupId>com.mulesoft.munit.tools</groupId>
                <artifactId>munit-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>
</project>
```

### Ignore a Parent Plugin

Each child project under a parent `pom.xml` file can ignore the plugin referenced in the parent
plugin management section and not implement the plugin configuration declared there.

By not declaring the MUnit Plugin in your `<plugin>` section, you avoid inheriting the plugin
declared in **pirate-pom**:

Child POM file not inheriting the MUnit Maven Plugin

```xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

    <parent>
        <groupId>org.pirate</groupId>
        <artifactId>pirate-pom</artifactId>
        <version>1.0-SNAPSHOT</version>
    </parent>

    <modelVersion>4.0.0</modelVersion>
    <groupId>com.mycompany</groupId>
    <artifactId>ninja</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>mule</packaging>
    <name>Mule ninja Application</name>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <mule.version>4.1.0</mule.version>
        <munit.version>2.3.0</munit.version>
    </properties>

    <build>
        <plugins>
            <plugin>
            </plugin>
        </plugins>
    </build>
</project>
```

### Override a Parent Plugin

When inheriting the plugin from a parent POM file, you can also override the parent configuration.
Overriding the plugin configuration from your parent POM file suppresses the original configuration
requiring you to declare all necessary configurations again.

The following example overrides the console coverage report from its parent POM file, replacing it
with the HTML report. Because the values from the other elements in the parent (`<failBuild>`,
`<requiredApplicationCoverage>`, `<requiredResourceCoverage>`, `<requiredFlowCoverage>`) aren’t
being referenced, this child file won’t inherit them and the default values are applied:

Coverage configuration in parent POM file

```xml
<coverage>
	<runCoverage>true</runCoverage>
	<failBuild>false</failBuild>
	<requiredApplicationCoverage>0</requiredApplicationCoverage>
	<requiredResourceCoverage>0</requiredResourceCoverage>
	<requiredFlowCoverage>0</requiredFlowCoverage>
	<formats>
		<format>console</format>
		<format>html</format>
	</formats>
</coverage>
```

POM child file overriding coverage report format

```xml
<plugin>
	<groupId>com.mulesoft.munit.tools</groupId>
	<artifactId>munit-maven-plugin</artifactId>
	<configuration>
		<coverage>
			<runCoverage>true</runCoverage>
			<formats>
				<format>html</format>
			</formats>
		</coverage>
	</configuration>
</plugin>
```

## Set Up Coverage

The following configurations only apply when you execute your MUnit tests using the Maven plugin.
They don’t apply when running tests from Studio. See
[Using Coverage in Maven](https://docs.mulesoft.com/munit/latest/coverage-maven-concept) for additional information.

Configure MUnit coverage reports in Maven by adding the munit-maven-plugin to your pom.xml and
enabling the coverage-report goal. Coverage reports are generated during the Maven site lifecycle
and are not available when running tests from Anypoint Code Builder or Anypoint Studio.

MUnit Coverage - Sample Maven configuration

```xml
<plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <version>${munit.version}</version>

    <executions>
        <execution>
            <id>test</id>
            <phase>test</phase>
            <goals>
                <goal>test</goal>
                <goal>coverage-report</goal>
            </goals>
        </execution>
    </executions>

    <configuration>
        <coverage>
            <runCoverage>true</runCoverage>
            <failBuild>false</failBuild>

            <requiredApplicationCoverage>75</requiredApplicationCoverage>
            <requiredResourceCoverage>50</requiredResourceCoverage>
            <requiredFlowCoverage>50</requiredFlowCoverage>

            <formats>
                <format>console</format>
                <format>html</format>
            </formats>
        </coverage>
    </configuration>
</plugin>
```

### Set Up a Minimum Coverage Level

One of the features of MUnit Coverage is to fail the build if a certain coverage level isn’t
reached.

MUnit Coverage handles three different levels:

- **Application**: The overall coverage of all your application.

- **Resource**: The coverage level of each Mule configuration file.

- **Flow**: The coverage of event processors in each flow.

To define the required coverage levels:

MUnit Coverage - Require Coverage

```xml
<coverage>
    <runCoverage>true</runCoverage>
    <failBuild>true</failBuild>

    <requiredApplicationCoverage>75</requiredApplicationCoverage> (1)
    <requiredResourceCoverage>50</requiredResourceCoverage>
    <requiredFlowCoverage>50</requiredFlowCoverage>
</coverage>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Each value represents a percentage.<br>If a percentage isn’t defined, it defaults to <strong>-1</strong>, which sets no requirements for said level so the build doesn’t fail due to low coverage.</td></tr></tbody></table>

If you define coverage levels but set the property `failBuild` to `false`, and then the levels
aren’t reached, a warning shows up in the MUnit Coverage summary:

```console
===============================================================================
MUnit Coverage Summary
===============================================================================
 * Resources: 2 - Flows: 3 - Processors: 4
 * Application Coverage: 75.00%

----------------------------- WARNING --------------------------------------
 * Flow: file2.xml -> file2Flow1 coverage is below defined limit. Required: 50.0% - Current: 00.00% (1)
====================================================================================
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Warning detailing which coverage level isn’t met, and where it happens.</td></tr></tbody></table>

### Ignore a Flow or a File

You can also ignore a flow or a file. This way, the ignored resource:

- Does not count as coverage data.

- Does not affect the overall number of message processors.

- Does not cause a build to fail if the flow isn’t tested or if the flow doesn’t reach coverage
  metrics.

To ignore flows and files:

MUnit Coverage - Ignore flows and files

```xml
<coverage>
    <runCoverage>true</runCoverage>
    <failBuild>true</failBuild>

    <requiredApplicationCoverage>100</requiredApplicationCoverage>
    <requiredResourceCoverage>100</requiredResourceCoverage>
    <requiredFlowCoverage>100</requiredFlowCoverage>

    <ignoreFlows>
        <ignoreFlow>flow-1</ignoreFlow>
        <ignoreFlow>flow-2</ignoreFlow>
        ...
        <ignoreFlow>flow-n</ignoreFlow>
    </ignoreFlows>

    <ignoreFiles>
        <ignoreFile>mule-config-1.xml</ignoreFile>
        <ignoreFile>mule-config-2.xml</ignoreFile>
        ...
        <ignoreFile>mule-config-n.xml</ignoreFile>
    </ignoreFiles>
</coverage>
```

## Dynamic Ports

MUnit 2.2 and later introduce the `dynamic-port` global element, that allows you to define dynamic
ports at the MUnit suite level. Using this element instead of the plugin configuration described as
follows allows you to set the dynamic port both from Maven and Studio.  
See [Dynamic Ports](https://docs.mulesoft.com/munit/latest/dynamic-ports) to learn how to configure this element.

When testing a Mule application in a continuous integration (CI) environment, you might encounter
the following scenario:

Your application tries to open a specific port. The port is already in use. The application fails
with a port binding exception.

The MUnit Maven Plugin comes with a built-in feature to make your application use a free port.

MUnit Dynamic Ports instructs the MUnit Maven Plugin to look for unbound ports and reserve them
before running the tests over the Mule application. Each port selected is placed in a system
property under the name indicated in the configuration. The application can get the port number
through the use of placeholders afterward.

The plugin selects the ports from the range: `[40000,50000]`

> [!CAUTION] Dynamic Ports feature is only available as part of the MUnit Maven Plugin. This feature
> does not work when running tests in Anypoint Studio.

### Enable Dynamic Ports

To enable the feature, you must add the following code to the `configuration` section of the MUnit
Maven Plugin:

Dynamic Ports Configuration

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
    ...
    <dynamicPorts>
      <dynamicPort>a.dynamic.port</dynamicPort>
    </dynamicPorts>
    ...
    </configuration>
  </plugin>
</plugins>
```

If you have the `${http.port}` placeholder in your application, the configuration looks something
like:

Example

```xml
<dynamicPorts>
  <dynamicPort>http.port</dynamicPort>
</dynamicPorts>
```

### Prepare Your Application

A placeholder must parameterize the part of the application trying to make use of a port. For
example, to have your Mule application listening for HTTP traffic, provide the following
configuration:

HTTP Application

```xml
<http:listener-config name="HTTP_Listener_config">
  <http:listener-connection host="0.0.0.0" port="8081" />
</http:listener-config>

<flow name="httpFlow">
  <http:listener path="/" config-ref="HTTP_Listener_config"/>
</flow>
```

The previous application always listens in port `8081`. To make it dynamic, change it to:

HTTP Application with dynamic port

```xml
<http:listener-config name="HTTP_Listener_config">
  <http:listener-connection host="0.0.0.0" port="${http.port}"/> (1)
</http:listener-config>

<flow name="httpFlow">
  <http:listener path="/" config-ref="HTTP_Listener_config"/>
</flow>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Notice the placeholder <code>${http.port}</code>.</td></tr></tbody></table>

With the application coded in this way and the configuration of Dynamic Ports in place, your
application starts each run listening on a different port.

## Enable Surefire Reports

MUnit has built-in support for Surefire. You mustn’t do additional configurations, and you can
disable it if not needed:

Disable Surefire reports

```none
<enableSurefireReports>false</enableSurefireReports>
```

You can find the reports under `${project.build.directory}/surefire-reports`.

By default, it’s set to `true`.

## Enable Sonar Reports

MUnit has built-in support for SonarQube, with a default setting of `true` for `enableSonarReports`.
No other configuration is required.

You can find the reports under `${project.build.directory}/sonar-reports`.

You can disable SONAR reports if not needed:

Disable Sonar reports

```none
<enableSonarReports>false</enableSonarReports>
```

You can find the reports under `${project.build.directory}/sonar-reports`.

By default, it’s set to `true`.

## Run Tests Using the Plugin

### Run MUnit Tests for a Mule Application

Run MUnit tests in a Single Resource Mule project.

```none
mvn clean test
```

### Run a Specific MUnit Test Suite

By using the property `munit.test`, you can instruct the MUnit Maven plugin to run certain tests
that belong to a specific test suite:

```maven
mvn clean test -Dmunit.test=<regex-test-suite>
```

This path is relative to `src/test/munit`.

The property `munit.test` accepts regular expressions. The expression is applied to the name of the
MUnit Test Suite file. The regular expression language is the Java implementation.

For example:

```console
mvn clean test -Dmunit.test=.*my-test.*
```

You can leverage this feature by adding naming conventions to your MUnit Test suites.

### Run Specific MUnit Tests

In the same way that you instruct MUnit to run one test suite, you can also configure it to run a
specific test in that test suite. You must use the property `munit.test` with the addition of the
special character `#` to append the test name:

```console
mvn clean test -Dmunit.test=<regex-test-suite>#<regex-test-name>
```

It also accepts regular expressions. The expression is applied to the attribute `name` of the MUnit
Test. For example:

```console
mvn clean test -Dmunit.test=.*my-test.*#.*test-scenario-1.*
```

MUnit flags the tests in the MUnit Test Suite that don’t match the regular expression as
**ignored**.

You can also configure this from the `pom.xml` configuration:

```xml
<plugins>
  <plugin>
      <groupId>com.mulesoft.munit.tools</groupId>
      <artifactId>munit-maven-plugin</artifactId>
      <configuration>
      ...
      <munitTest>example-MunitTest-suite.xml</munitTest>
      ...
    </configuration>
  </plugin>
</plugins>
```

### Run Tests Using a Specific Tag

You can run the tests that you grouped under one specific tag:

```console
mvn clean test -Dmunit.tags=<munit-tag>
```

You can also configure this from the `pom.xml` configuration:

```xml
<plugins>
  <plugin>
      <groupId>com.mulesoft.munit.tools</groupId>
      <artifactId>munit-maven-plugin</artifactId>
      <configuration>
      ...
      <munitTags>exampleMunitTag</munitTags>
      ...
    </configuration>
  </plugin>
</plugins>
```

You can specify more than one tag by separating them with a comma.

### Fail When No Tests Run

By default, MUnit fails the Maven build if it can’t find any MUnit test suites or if no tests run
from the discovered suites. This behavior helps ensure that applications in a CI pipeline include
and run MUnit tests.

To allow a build to succeed when no MUnit tests run, set `munitFailIfNoTests` to `false` in the
MUnit Maven Plugin configuration:

Allow builds with no MUnit tests

```xml
<plugins>
  <plugin>
      <groupId>com.mulesoft.munit.tools</groupId>
      <artifactId>munit-maven-plugin</artifactId>
      <configuration>
      ...
      <munitFailIfNoTests>false</munitFailIfNoTests>
      ...
    </configuration>
  </plugin>
</plugins>
```

You can also disable this behavior from the command line:

```console
mvn clean test -Dmunit.failIfNoTests=false
```

Use this setting only when no MUnit tests are expected to run. Maven’s `skipTests` parameter and
MUnit’s `skipMunitTests` parameter skip MUnit test execution and don’t run this validation.

### Skip All Tests

MUnit leverages the same mechanism as Maven. To skip tests, you must use the `skipTests` parameter:

Skip Tests example

```console
mvn clean package -DskipTests
```

You can also configure this from the `pom.xml` configuration:

```xml
<plugins>
  <plugin>
      <groupId>com.mulesoft.munit.tools</groupId>
      <artifactId>munit-maven-plugin</artifactId>
      <configuration>
      ...
      <skipMunitTests>true</skipMunitTests>
      ...
    </configuration>
  </plugin>
</plugins>
```

### Skip Tests After One Suite Fails

MUnit allows you to skip the rest of the tests if one test suite fails:

```xml
<plugins>
  <plugin>
      <groupId>com.mulesoft.munit.tools</groupId>
      <artifactId>munit-maven-plugin</artifactId>
      <configuration>
      ...
      <skipAfterFailure>true</skipAfterFailure>
      ...
    </configuration>
  </plugin>
</plugins>
```

If not specified, it’s default value is `false`.

## Specify the Runtime Product

You can specify the type of runtime in which the applications you test run. Accepted values are:

- `MULE` for the Mule Kernel (formerly called Mule Community Edition)

- `MULE_EE` for the Mule Enterprise Edition

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <runtimeProduct>MULE</runtimeProduct>
      ...
    </configuration>
  </plugin>
</plugins>
```

### Specify the Runtime Product Version

You can specify the runtime version in which the applications you test run.

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <munit.runtimeversion>4.2.2</munit.runtimeversion>
      ...
    </configuration>
  </plugin>
</plugins>
```

The `munit.runtimeversion` property replaces the deprecated `runtimeVersion` property. The
`runtimeVersion` property remains supported. If you use `runtimeVersion`, MUnit displays a warning
message that indicates the property is deprecated and that you must migrate to
`munit.runtimeversion`.

## Specify the JVM

You can specify the JVM (or the Java executable) in which the applications you test run. You must
populate the `munit.jvm` parameter with the path to the executable:

Specify the JVM

```console
mvn clean package -Dmunit.jvm=/path/to/jdk/bin/java
```

You can also configure this from the `pom.xml` configuration:

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <jvm>/path/to/jdk/bin/java</jvm>
      ...
    </configuration>
  </plugin>
</plugins>
```

### Additional Argument Lines

You can pass additional argument lines to the JVM. Specify each argument in a separate `argLine`:

Argument lines

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <argLines>
          <argLine>-XX:MaxPermSize=512m</argLine>
          <argLine>-Xmx1024m</argLine>
      </argLines>
      ...
    </configuration>
  </plugin>
</plugins>
```

### Environment Variables

To set additional environment variables during the test run, you can specify them with the
respective key and value:

Additional Environment Variables

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <environmentVariables>
        <MY_ENV>exampleValue</MY_ENV>
        <MY_OTHER_ENV>val2</MY_OTHER_ENV>
      </environmentVariables>
      ...
    </configuration>
  </plugin>
</plugins>
```

As shown in the previous example, you can use environment variables to replace placeholders such as
`${MY_ENV}`.

### System Properties Variables

If you must define specific system variables to run your MUnit test successfully:

Setting system property variables

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <systemPropertyVariables>
        <my.property.key>my.property.value</my.property.key>
      </systemPropertyVariables>
      ...
    </configuration>
  </plugin>
</plugins>
```

Depending on the execution context, the system property values can vary. When referencing these
properties, you must override their value to enforce test reproducibility.

You can do so by using the ­`-D` argument when running MUnit with Maven. Variables passed with the
`-D` argument take full priority over any other property. For example:

```none
-Dmy.property.key=my.property.another.value
```

## Redirect Test Output to File

When running several tests, the build output can get very complex to read. MUnit allows you to
redirect the output of each test suite to a file. This way, the test results remain in the build
output and you can check the respective file to check the standard output of each test suite.

You can find these files in the `testOutputDirectory` folder following the naming convention:
`munit.${suiteName}-output.txt`, where `suiteName` represents the name of the XML file relative to
the MUnit test folder.

The test output that doesn’t belong to a particular suite isn’t printed to keep the build output
clean. You can enable it by running Maven in debug mode.

To redirect the output of each test suite to a file:

Redirect test output to a file

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <redirectTestOutputToFile>true</redirectTestOutputToFile>
      ...
    </configuration>
  </plugin>
</plugins>
```

By default, it’s set to `false`.

### Test Output Directory

If you want to choose the location where the test creates the output files, the path specified can
be absolute or written as a Maven placeholder:

Test output directory with absolute path

```xml
<plugins>
  <plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <configuration>
      ...
      <testOutputDirectory>/my/absolute/path</testOutputDirectory>
      ...
    </configuration>
  </plugin>
</plugins>
```

Test output directory using Maven placeholders

```xml
<testOutputDirectory>${project.build.directory}/my/output/folder</testOutputDirectory>
```

By default, the files are created in `${project.build.directory}/munit-reports/output/`.

## MUnit Maven Plugin Configuration Reference

The MUnit Maven Plugin offers a set of optional configurable parameters.

<table><caption>Table 1. Maven Plugin Parameters</caption> <colgroup><col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><code>argLines</code></p></div></div></td><td><div><div><p>List</p></div></div></td><td><div><div><p>Additional JVM argument lines to set on the test run.</p></div></div></td></tr><tr><td><div><div><p><code>coverage</code></p></div></div></td><td><div><div><p>Configuration</p></div></div></td><td><div><div><p>Coverage configuration to set on the test run.</p></div></div></td></tr><tr><td><div><div><p><code>dynamicPorts</code></p></div></div></td><td><div><div><p>List</p></div></div></td><td><div><div><p>Dynamic ports to set on the test run.</p></div></div></td></tr><tr><td><div><div><p><code>enableSurefireReports</code></p></div></div></td><td><div><div><p>boolean</p></div></div></td><td><div><div><p>Set value to <code>true</code> to generate MUnit test results in the Surefire format.<br>Its default value is <code>true</code>.</p></div></div></td></tr><tr><td><div><div><p><code>munitTest</code></p></div></div></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the MUnit tests to run.</p></div></div></td></tr><tr><td><div><div><p><code>munitTags</code></p></div></div></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the MUnit tags. Tests tagged with these names run.</p></div></div></td></tr><tr><td><div><div><p><code>munitFailIfNoTests</code></p></div></div></td><td><div><div><p>boolean</p></div></div></td><td><div><div><p>Fails the Maven build if no MUnit test suites are found or no tests run from the discovered suites.<br>Its default value is <code>true</code>.</p></div></div></td></tr><tr><td><div><div><p><code>skipMunitTests</code></p></div></div></td><td><div><div><p>boolean</p></div></div></td><td><div><div><p>Setting this parameter to <code>true</code> skips all MUnit tests.<br>Its default value is <code>false</code>.</p></div></div></td></tr><tr><td><div><div><p><code>skipAfterFailure</code></p></div></div></td><td><div><div><p>boolean</p></div></div></td><td><div><div><p>Skip all tests if one fails.<br>Its default value is <code>false</code>.</p></div></div></td></tr><tr><td><div><div><p><code>munitTestsDirectory</code></p></div></div></td><td><div><div><p>File</p></div></div></td><td><div><div><p>Directory where the MUnit tests reside.<br>Its default value is <code>${project.build.directory}/test-mule/munit</code>.</p></div></div></td></tr><tr><td><div><div><p><code>munit.runtimeversion</code></p></div></div></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Version of the Mule runtime<br>When you run your tests from Maven, this value comes from the <code>minMuleVersion</code> parameter in the <code>mule-artifact.json</code> file.<br>To modify the Mule runtime version used to run your MUnit tests, see <a href="https://docs.mulesoft.com/munit/latest/runtime-patching">Runtime Patching</a>.</p></div></div></td></tr><tr><td><div><div><p><code>runtimeVersion</code> (deprecated)</p></div></div></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Deprecated alias for <code>munit.runtimeversion</code>.<br>This property remains supported for backward compatibility.<br>When you use this property, MUnit displays a warning message and instructs you to migrate to <code>munit.runtimeversion</code>.</p></div></div></td></tr><tr><td><div><div><p>runtimeProduct</p></div></div></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Type of runtime. Expected values are:</p></div><div><ul><li><p><code>MULE</code> for the Mule Kernel (formerly called Mule Community Edition)</p></li><li><p><code>MULE_EE</code> for the Mule Enterprise Edition</p></li></ul></div><div><p>By default, this value comes from the <code>requiredProduct</code> parameter in the <code>mule-artifact.json</code> file.</p></div></div></td></tr><tr><td><div><div><p><code>jvm</code></p></div></div></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Option to specify the JVM (or path to the Java executable) to use.</p></div><div><p>By default, the JVM is the same VM as the one used to run Maven.</p></div></div></td></tr><tr><td><div><div><p><code>environmentVariables</code></p></div></div></td><td><div><div><p>Map</p></div></div></td><td><div><div><p>Additional environment variables to set on the test run.</p></div></div></td></tr><tr><td><div><div><p><code>redirectTestOutputToFile</code></p></div></div></td><td><div><div><p>boolean</p></div></div></td><td><div><div><p>Setting this value to <code>true</code> redirects the MUnit tests standard output to a file.<br>Its default value is <code>false</code>.</p></div></div></td></tr><tr><td><div><div><p><code>systemPropertyVariables</code></p></div></div></td><td><div><div><p>Map</p></div></div></td><td><div><div><p>System properties set on the test run.</p></div></div></td></tr><tr><td><div><div><p><code>testOutputDirectory</code></p></div></div></td><td><div><div><p>File</p></div></div></td><td><div><div><p>Directory where the test outputs are written.<br>Its default value is <code>${project.build.directory}/munit-reports/output/</code>.</p></div></div></td></tr></tbody></table>

<!-- document id=0b2ac4732d913e26d08740bf2fef2c50ed767b782b68b85792e3c4cb37551755 url=/mulesoft/current/en-us/munit/latest/mock-event-processor.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
keywords: munit, testing, unit testing
---

# MUnit Mock When Event Processor

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The MUnit Mock When processor intercepts a specified event processor during a MUnit test and returns
a configured response instead of executing the real operation. Use it to isolate the flow under test
from external dependencies such as HTTP requests, database calls, or web service operations.

For example, you can use the **Mock Event** processor to mock a POST request with a mocked payload:

```xml
<munit-tools:mock-when processor="http:request">
   <munit-tools:with-attributes>
       <munit-tools:with-attribute attributeName="method" whereValue="#['POST']"/>
   </munit-tools:with-attributes>
   <munit-tools:then-return>
       <munit-tools:payload value="#['mockPayload']"/>
   </munit-tools:then-return>
</munit-tools:mock-when>
```

You can set the **processor** attribute to define the processor to mock and set the
**with-attribute** element to define the attribute name and value. In the previous example, you
define a POST method.

You can also use DataWeave functions and mappings to set the `value` attribute in the
**then-return** element. For example, create a **mockPost.dwl** in the
**src/test/resources/sample\_data** file:

```none
%dw 2.0
output application/json
---
{
	"foo" : "var"
}
```

This DataWeave file creates the payload to send in a POST request. You can then use the **readUrl**
DataWeave function to read the mapping file:

```xml
<munit-tools:then-return>
  <munit-tools:payload value="#[readUrl('classpath://sample_data/mockPost.dwl')]" mediaType="application/json" encoding="UTF-8" />
</munit-tools:then-return>
```

Finally, you can configure a **then-return** element to define the type of response the mocked
processor returns. It can be a payload, a variable, a list of attributes, or an error.

You can use either a **then-return** to return a static, constant value, or you can use a
**then-call** to invoke a flow for cases where the returned value can change over time, or to have
different responses according to certain inputs.

> [!NOTE] The mocking of the processors is executed after the initialization of the Mule app, and
> some connectors can require credentials or configurations to start the app, even when its
> processors are mocked.

> [!NOTE] Logger processor and Transform Message processor (DataWeave) cannot be mocked.

## Mock Using Then-Return

For example, you can mock a web service consumer such as this one:

```xml
<wsc:config name="Web_Service_Consumer_Config">
  <wsc:connection wsdlLocation="tshirt.wsdl" service="TshirtService" port="TshirtServicePort" address="http://tshirt-service.cloudhub.io"/>
</wsc:config>

<wsc:consume config-ref="Web_Service_Consumer_Config" operation="OrderTshirt"/>
```

By configuring the **mock-when** processor as shown in the following example:

```xml
<munit-tools:mock-when processor="wsc:consume">
    <munit-tools:with-attributes>
        <munit-tools:with-attribute attributeName="operation" whereValue="#['OrderTshirt']"/>
    </munit-tools:with-attributes>
</munit-tools:mock-when>
```

This **mock-when** processor mocks a call to the **OrderTshirt** operation in the WSDL definition.

You can also mock specific variables:

```xml
<munit-tools:mock-when processor="http:request">
	<munit-tools:with-attributes>
	    <munit-tools:with-attribute attributeName="config-ref" whereValue="#['HTTP_Request_configuration']"/>
	</munit-tools:with-attributes>
	<munit-tools:then-return>
	  <munit-tools:variables>
	  	<munit-tools:variable key="aVariable" value="#['aValue']"/>
	  </munit-tools:variables>
	</munit-tools:then-return>
</munit-tools:mock-when>
```

### Mock Errors

The **Mock When** processor also enables you to mock errors in your operations. Assume that you have
an HTTP requester in your flow with an On-Error scope that catches any connectivity errors and
returns a custom payload if the connection fails:

```xml
<http:request-config name="HTTP_Request_Config">
    <http:request-connection host="localhost" port="8888"/>
</http:request-config>

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

<flow name="api-request">
    <http:listener config-ref="HTTP_Listener_Config" path="/"/>
    <http:request method="GET" config-ref="HTTP_Request_Config" path="/api"/>
    <error-handler>
        <on-error-continue enableNotifications="true" logException="true" type="HTTP:CONNECTIVITY">
            <set-payload value="#['Connection Error']"/>
        </on-error-continue>
    </error-handler>
</flow>
```

You can assert that every time the HTTP request fails, your application returns your custom payload:

```xml
<munit:test name="HTTP-fail-test" description="Asserts Custom Payload in HTTP Connectivity errors.">
    <munit:behavior>
        <munit-tools:mock-when processor="http:request">
            <munit-tools:with-attributes>
                <munit-tools:with-attribute attributeName="config-ref"
                                            whereValue="#['HTTP_Request_Config']"/> (1)
            </munit-tools:with-attributes>

            <munit-tools:then-return>
                <munit-tools:error typeId="#['HTTP:CONNECTIVITY']"/> (2)
            </munit-tools:then-return>
        </munit-tools:mock-when>
    </munit:behavior>

    <munit:execution>
        <flow-ref name="api-request"/> (3)
    </munit:execution>

    <munit:validation>
      <munit-tools:assert-that expression="#[payload]" is="#[MunitTools::equalToIgnoringCase('connection error')]"/> (4)
    </munit:validation>
</munit:test>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Mock an HTTP Requester with the configuration of the requester in your flow.</td></tr><tr><td><i data-value="2"></i><b>2</b></td><td>Configure a then-return element to throw an <strong>HTTP:CONNECTIVITY</strong> error.<br>This triggers the On-error scope in your application.</td></tr><tr><td><i data-value="3"></i><b>3</b></td><td>Execute the flow containing the requester.</td></tr><tr><td><i data-value="4"></i><b>4</b></td><td>Assert that the returned payload is the one you set in the On-error scope.</td></tr></tbody></table>

You cannot return all known error types of a Mule application. You can return the type of errors
defined in the modules the current flow uses. If you try to return an error type that is out of the
scope of the flow you’re testing, you get a **MULE:UNKNOWN** error instead of the configured one.

### Parameters

If you create a mock error, choose one of the following parameters to provide the trigger for the
error in the **Then-return** tab:

- **TypeId**: Follows a Mule Error type definition. For example, the HTTP:CONNECTIVITY error
  explained before.

- **Cause**: Expects the instance of the exception with a message for the error. For example, using
  Java, write the expression:

```java
#[java!java::lang::Exception::new("Exception Message")]
```

## Mock Using Then-Call

To dynamically mock a variable, use **then-call** as follows:

```xml
<flow name="flow-to-be-mocked">
    <set-variable variableName="count" value="#[0]"/>
</flow>

<flow name="flow-to-test">
    <flow-ref name="flow-to-be-mocked"/> (1)
</flow>

<flow name="count-to-3"> (2)
    <choice>
        <when expression="#[vars.count == null]">
            <set-variable variableName="count" value="#[1]" doc:name="Create counter"/>
        </when>

        <when expression="#[vars.count &lt; 3]">
            <set-variable variableName="count" value="#[vars.count + 1]"
                          doc:name="Increase count by 1, up to 3"/>
        </when>
    </choice>
</flow>

<munit:test name="variable-mock-test">
    <munit:behavior>
        <munit-tools:mock-when processor="mule:flow-ref">
            <munit-tools:with-attributes>
                <munit-tools:with-attribute attributeName="name" whereValue="#['flow-to-be-mocked']"/>
            </munit-tools:with-attributes>

            <munit-tools:then-call flow="count-to-3"/> (3)
        </munit-tools:mock-when>
    </munit:behavior>

    <munit:execution>
        <flow-ref name="flow-to-test"/> <!-- 1 -->
        <flow-ref name="flow-to-test"/> <!-- 2 -->
        <flow-ref name="flow-to-test"/> <!-- 3 -->
        <flow-ref name="flow-to-test"/> <!-- 3 -->
    </munit:execution>

    <munit:validation>
        <munit-tools:assert-that expression="#[vars.count]" is="#[MunitTools::equalTo(3)]"/>
    </munit:validation>
</munit:test>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>This is the processor you mock.</td></tr><tr><td><i data-value="2"></i><b>2</b></td><td>The mock calls this flow. The mock sets a variable that changes depending on the incoming event.</td></tr><tr><td><i data-value="3"></i><b>3</b></td><td>Configure the mock to call the desired flow.</td></tr></tbody></table>

## See Also

- [Assert That Event Processor](https://docs.mulesoft.com/munit/latest/assertion-event-processor)

- [Fail Event Processor](https://docs.mulesoft.com/munit/latest/fail-event-processor)

- [Run Custom Event Processor](https://docs.mulesoft.com/munit/latest/run-custom-event-processor)

- [Set Event Processor](https://docs.mulesoft.com/munit/latest/set-event-processor)

- [Verify Event Processor](https://docs.mulesoft.com/munit/latest/verify-event-processor)

<!-- document id=1d4b3bedc7dc4c43876a9abbb692abc226c300be7bd9bb527e8653884f8a2db1 url=/mulesoft/current/en-us/munit/3.6/index.md -->

---
product: MUnit
version: 3.6
---

# MUnit Overview

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

Build automated tests for your integrations and APIs with MUnit. MUnit is a Mule application testing
framework that provides a full suite of integration and unit test capabilities, and is fully
integrated with Maven and Surefire for integration with your continuous deployment environment.

MUnit version 3.0 and later works with all Mule versions since 4.3.

With MUnit you can:

- Create your test by writing Mule code

- Mock processors

- Spy any processor

- Verify processor calls

- Enable or ignore particular tests

- Tag tests

- Generate coverage reports

You can create, design, and run MUnit tests in Anypoint Studio and Anypoint Code Builder.

MUnit has two main sub modules:

- MUnit

- MUnit Tools

Each module has its dependency:

## MUnit Dependencies

```xml
<dependency>
	<groupId>com.mulesoft.munit</groupId>
	<artifactId>munit-runner</artifactId>
	<version>LATEST_VERSION</version> (1)
	<classifier>mule-plugin</classifier>
	<scope>test</scope>
</dependency>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Check the <a href="https://docs.mulesoft.com/munit/3.6/munit-release-notes">MUnit Release Notes</a> to get the <strong>LATEST_VERSION</strong>.</td></tr></tbody></table>

## MUnit Tools Dependencies

```xml
<dependency>
	<groupId>com.mulesoft.munit</groupId>
	<artifactId>munit-tools</artifactId>
	<version>LATEST_VERSION</version> (1)
	<classifier>mule-plugin</classifier>
	<scope>test</scope>
</dependency>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Check the <a href="https://docs.mulesoft.com/munit/3.6/munit-release-notes">MUnit Release Notes</a> to get the <strong>LATEST_VERSION</strong>.</td></tr></tbody></table>

## See Also

- [MUnit Test Structure Fundamentals](https://docs.mulesoft.com/munit/3.6/munit-test-concept)

- [MUnit Cookbook](https://docs.mulesoft.com/munit/3.6/munit-cookbook)

- [Testing Projects with MUnit in Studio](https://docs.mulesoft.com/studio/test-with-munit-in-studio)

- [Testing Projects with MUnit in Anypoint Code Builder](https://docs.mulesoft.com/anypoint-code-builder/int-test-munit)

<!-- document id=f39db148d1316712f9e4fbb3e014e9b98e2c19a6bc92cc5fa2e7ade66f612e7d url=/mulesoft/current/en-us/munit/latest/index.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit Overview

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

Build automated tests for your integrations and APIs with MUnit. MUnit is a Mule application testing
framework that provides a full suite of integration and unit test capabilities, and is fully
integrated with Maven and Surefire for integration with your continuous deployment environment.

MUnit version 3.0 and later works with all Mule versions since 4.3.

With MUnit you can:

- Create your test by writing Mule code

- Mock processors

- Spy any processor

- Verify processor calls

- Enable or ignore particular tests

- Tag tests

- Generate coverage reports

You can create, design, and run MUnit tests in Anypoint Studio and Anypoint Code Builder.

MUnit has two main sub modules:

- MUnit

- MUnit Tools

Each module has its dependency:

## MUnit Dependencies

```xml
<dependency>
	<groupId>com.mulesoft.munit</groupId>
	<artifactId>munit-runner</artifactId>
	<version>LATEST_VERSION</version> (1)
	<classifier>mule-plugin</classifier>
	<scope>test</scope>
</dependency>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Check the <a href="https://docs.mulesoft.com/munit/latest/munit-release-notes">MUnit Release Notes</a> to get the <strong>LATEST_VERSION</strong>.</td></tr></tbody></table>

## MUnit Tools Dependencies

```xml
<dependency>
	<groupId>com.mulesoft.munit</groupId>
	<artifactId>munit-tools</artifactId>
	<version>LATEST_VERSION</version> (1)
	<classifier>mule-plugin</classifier>
	<scope>test</scope>
</dependency>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Check the <a href="https://docs.mulesoft.com/munit/latest/munit-release-notes">MUnit Release Notes</a> to get the <strong>LATEST_VERSION</strong>.</td></tr></tbody></table>

## See Also

- [MUnit Test Structure Fundamentals](https://docs.mulesoft.com/munit/latest/munit-test-concept)

- [MUnit Cookbook](https://docs.mulesoft.com/munit/latest/munit-cookbook)

- [Testing Projects with MUnit in Studio](https://docs.mulesoft.com/studio/test-with-munit-in-studio)

- [Testing Projects with MUnit in Anypoint Code Builder](https://docs.mulesoft.com/anypoint-code-builder/int-test-munit)

<!-- document id=e3d4097a1c229f8630730fa711942f8573a5bc54315acb01531ba4337adcfbec url=/mulesoft/current/en-us/munit/latest/parameterized.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
keywords: munit, testing, unit testing
---

# MUnit Parameterized Test Suites

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

MUnit parameterized test suites run the same tests multiple times with different input values,
reducing duplication in your test code. Define parameterizations inline in the test suite
configuration or load them from a YAML file in your project’s test resources.

The test suite parameterization is defined at a configuration level as follows:

```xml
<munit:config>
    <munit:parameterizations>
        <munit:parameterization name="firstParameterization">
            <munit:parameters>
                <munit:parameter propertyName="name" value="Robert"/>
                <munit:parameter propertyName="lastname" value="Plant"/>
            </munit:parameters>
        </munit:parameterization>
        <munit:parameterization name="secondParameterization">
            <munit:parameters>
                <munit:parameter propertyName="name" value="Jimmy"/>
                <munit:parameter propertyName="lastname" value="Page"/>
            </munit:parameters>
        </munit:parameterization>
    </munit:parameterizations>
</munit:config>
```

The Test Suite runs twice: Firstly, with the `firstParameterization` parameters. Secondly, with the
`secondParameterization` parameters.

For example, if you have a test that sets a payload for a flow and expects a result:

Parameterization Example

```xml
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns="http://www.mulesoft.org/schema/mule/core"
      xmlns:munit="http://www.mulesoft.org/schema/mule/munit"
      xmlns:munit-tools="http://www.mulesoft.org/schema/mule/munit-tools"
      xsi:schemaLocation="
        http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
        http://www.mulesoft.org/schema/mule/munit http://www.mulesoft.org/schema/mule/munit/current/mule-munit.xsd
        http://www.mulesoft.org/schema/mule/munit-tools http://www.mulesoft.org/schema/mule/munit-tools/current/mule-munit-tools.xsd">

    <munit:config name="parameterized-test.xml">
        <munit:parameterizations>
            <munit:parameterization name="sumThree">
                <munit:parameters>
                    <munit:parameter propertyName="input" value="#[1]"/>
                    <munit:parameter propertyName="output" value="#[2]"/>
                </munit:parameters>
            </munit:parameterization>
            <munit:parameterization name="sumFive">
                <munit:parameters>
                    <munit:parameter propertyName="input" value="#[2]"/>
                    <munit:parameter propertyName="output" value="#[4]"/>
                </munit:parameters>
            </munit:parameterization>
        </munit:parameterizations>
    </munit:config>

    <munit:test name="expectFlowResult">
        <munit:behavior>
            <set-payload value="${input}"/>
        </munit:behavior>
        <munit:execution >
            <flow-ref name="myFlow"/>
        </munit:execution>
        <munit:validation>
            <munit-tools:assert-equals actual="#[payload]" expected="${output}" />
        </munit:validation>
    </munit:test>

</mule>
```

## Access Parameters from DataWeave

Use the DataWeave `p()` function to access parameter values inside DataWeave expressions,
concatenate parameter values with other strings, perform comparisons or calculations, and use
parameters in complex DataWeave transformations.

Using the parameterization from the first example, the following test uses `p()` to build a greeting
message and validate that the payload contains the expected name:

Accessing Parameters with the p() Function

```xml
<munit:test name="validateGreeting">
    <munit:behavior>
        <set-payload value="#['Hello, ' ++ p('name') ++ ' ' ++ p('lastname')]"/>
    </munit:behavior>
    <munit:validation>
        <munit-tools:assert-that
          expression="#[payload contains p('name')]"
          is="#[MunitTools::equalTo(true)]"/>
    </munit:validation>
</munit:test>
```

## Parameterization from File

To use the same parameterized values on different test suites, you must save your parameterizations
values in a YAML file in the `/test/resources` directory of your Mule application project:

parameterizations.yaml Example

```yaml
firstParameterization:
  name: "Robert"
  lastname: "Plant"

secondParameterization:
  name: "Jimmy"
  lastname: "Page"
```

And reference it from your test suite configuration:

Example Parameterization From File

```xml
<munit:config>
    <munit:parameterizations file="parameterizations.yaml" />
</munit:config>
```

You can combine both methods to add parameterized values to a test suite:

Example Parameterization From File and in the Test Suite Configuration

```xml
<munit:config name="parameterization-from-file-test.xml">
    <munit:parameterizations file="parameterizations.yaml" >
        <munit:parameterization name="thirdParameterization">
            <munit:parameters>
                <munit:parameter propertyName="name" value="John"/>
                <munit:parameter propertyName="lastname" value="Bonham"/>
            </munit:parameters>
        </munit:parameterization>
    </munit:parameterizations>
</munit:config>
```

If you define the same parameterization key in a YAML file and your test suite configuration, the
test suite parameterization overrides your YAML parameterization.

## See Also

- [DataWeave Function: p(propertyName: String): String](https://docs.mulesoft.com/dataweave/latest/dw-mule-functions-p)

<!-- document id=cb283125eca7ea035349e04919fb6a753a2dbbe7560a12ccccd7574f0ebeaaf6 url=/mulesoft/current/en-us/munit/latest/queue-processors.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
keywords: munit, testing, unit testing, queue
---

# MUnit Queue Event Processors

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

MUnit Queue event processors manage temporary in-memory queues during MUnit test runs, letting you
enqueue and dequeue values to test asynchronous flows. All queues are cleared automatically when
each test ends.

## Queue

Adds the value to the queue. If not specified, the value is taken from the `payload`.

```xml
<munit-tools:queue>
    <munit-tools:value>#[1]</munit-tools:value>
</munit-tools:queue>
```

You can specify the queue’s name to which the value should be added. If not specified, the default
queue will be used.

```xml
<munit-tools:queue queueName="CUSTOM_QUEUE_1">
    <munit-tools:value>#[1]</munit-tools:value>
</munit-tools:queue>
```

## Dequeue

Removes the last element of the queue, if the queue is empty, it waits until an element is queued.

```xml
<munit-tools:dequeue/>
```

You can specify a timeout when waiting for an element to be queued:

```xml
<munit-tools:dequeue timeout="1000" timeoutUnit="SECONDS"/>
```

Like the queue operation, you can specify the queue’s name from which to dequeue. If not specified,
the default queue will be used.

```xml
<munit-tools:dequeue queueName="CUSTOM_QUEUE_1"/>
```

## Queue Size

Function that obtains the queue size.

```xml
<munit-tools:assert-that expression="#[MunitTools::queueSize()]" is="#[MunitTools::equalTo(2)]" />
```

Like the other operations, you can specify the queue from which to the get the size. If not
specified, the default queue will be used.

```xml
<munit-tools:assert-that expression="#[MunitTools::queueSize('CUSTOM_QUEUE_1')]" is="#[MunitTools::equalTo(2)]" />
```

<!-- document id=596291f515815fc282ebb5596995ee7061d075c07c62d8d464b7a4c6ba480696 url=/mulesoft/current/en-us/munit/2.3/munit-release-notes.md -->

---
product: MUnit
version: 2.3
keywords: munit, testing, unit testing, release notes
---

# MUnit Release Notes

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

These release notes are provided for MUnit.

## MUnit 3.x

- [MUnit 3.7.5 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.7.5-release-notes)

- [MUnit 3.7.4 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.7.4-release-notes)

- [MUnit 3.7.3 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.7.3-release-notes)

- [MUnit 3.7.2 Release Notes (Deprecated)](https://docs.mulesoft.com/release-notes/munit/munit-3.7.2-release-notes)

- [MUnit 3.7.1 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.7.1-release-notes)

- [MUnit 3.7.0 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.7.0-release-notes)

- [MUnit 3.6.3 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.6.3-release-notes)

- [MUnit 3.6.2 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.6.2-release-notes)

- [MUnit 3.6.1 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.6.1-release-notes)

- [MUnit 3.6.0 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.6.0-release-notes)

## MUnit 2.x

- [MUnit 2.3.18 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-2.3.18-release-notes)

> [!NOTE] For previous versions of MUnit 1.x, 2.x, and 3.x that reached
> [end of life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf),
> see the
> [MUnit Release Notes Archive](https://archive.docs.mulesoft.com/release-notes/munit/munit-archive).

## See Also

- [Known Issues](https://help.salesforce.com/s/issues)

<!-- document id=e91dbb6d0e343b9c5525a4cf2dce3674867a6d293c483761587930ba3f01d404 url=/mulesoft/current/en-us/munit/3.6/munit-release-notes.md -->

---
product: MUnit
version: 3.6
keywords: munit, testing, unit testing, release notes
---

# MUnit Release Notes

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

These release notes are provided for MUnit.

## MUnit 3.x

- [MUnit 3.7.5 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.7.5-release-notes)

- [MUnit 3.7.4 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.7.4-release-notes)

- [MUnit 3.7.3 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.7.3-release-notes)

- [MUnit 3.7.2 Release Notes (Deprecated)](https://docs.mulesoft.com/release-notes/munit/munit-3.7.2-release-notes)

- [MUnit 3.7.1 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.7.1-release-notes)

- [MUnit 3.7.0 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.7.0-release-notes)

- [MUnit 3.6.3 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.6.3-release-notes)

- [MUnit 3.6.2 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.6.2-release-notes)

- [MUnit 3.6.1 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.6.1-release-notes)

- [MUnit 3.6.0 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.6.0-release-notes)

## MUnit 2.x

- [MUnit 2.3.18 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-2.3.18-release-notes)

> [!NOTE] For previous versions of MUnit 1.x, 2.x, and 3.x that reached
> [end of life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf),
> see the
> [MUnit Release Notes Archive](https://archive.docs.mulesoft.com/release-notes/munit/munit-archive).

## See Also

- [Known Issues](https://help.salesforce.com/s/issues)

<!-- document id=ac49f01feffa10ec325b36e4a2a7be016f847e3a16aeb9993caea62569033529 url=/mulesoft/current/en-us/munit/latest/munit-release-notes.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
keywords: munit, testing, unit testing, release notes
---

# MUnit Release Notes

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

These release notes are provided for MUnit.

## MUnit 3.x

- [MUnit 3.7.5 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.7.5-release-notes)

- [MUnit 3.7.4 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.7.4-release-notes)

- [MUnit 3.7.3 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.7.3-release-notes)

- [MUnit 3.7.2 Release Notes (Deprecated)](https://docs.mulesoft.com/release-notes/munit/munit-3.7.2-release-notes)

- [MUnit 3.7.1 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.7.1-release-notes)

- [MUnit 3.7.0 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.7.0-release-notes)

- [MUnit 3.6.3 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.6.3-release-notes)

- [MUnit 3.6.2 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.6.2-release-notes)

- [MUnit 3.6.1 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.6.1-release-notes)

- [MUnit 3.6.0 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-3.6.0-release-notes)

## MUnit 2.x

- [MUnit 2.3.18 Release Notes](https://docs.mulesoft.com/release-notes/munit/munit-2.3.18-release-notes)

> [!NOTE] For previous versions of MUnit 1.x, 2.x, and 3.x that reached
> [end of life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf),
> see the
> [MUnit Release Notes Archive](https://archive.docs.mulesoft.com/release-notes/munit/munit-archive).

## See Also

- [Known Issues](https://help.salesforce.com/s/issues)

<!-- document id=7f7fa817a089119e9b8c412eb24c4602cd3ead4d5f12f338f6c8d0f5c9a77eb0 url=/mulesoft/current/en-us/munit/latest/resource-matchers-reference.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit Resource Matchers Reference

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

MUnit resource matchers are utility functions that read test resource files and create Mule messages
during a MUnit test. Use them to load file contents as streams, strings, or byte arrays, and to
inspect queue sizes in your test validations.

## getResourceAsStream(String)

Returns the resource from the path String as a stream.

Example

```xml
<set-payload
  value="#[MunitTools::getResourceAsStream('util/files/example.txt')]"/>
```

## getResourceAsReusableStream(String)

Returns the resource from the path String as a reusable stream.

Example

```xml
 <set-payload
   value="#[MunitTools::getResourceAsReusableStream('util/files/example.txt')]"/>
```

## getResourceAsString(path:String,encoding:String)

Returns the resource from the path String as a String, where the second parameter (encoding) is
optional.

Example

```xml
<set-payload
  value="#[MunitTools::getResourceAsString('util/files/example.txt')]"/>
```

You can also specify the encoding:

Example

```xml
<set-payload
  value="#[MunitTools::getResourceAsString('util/files/exampleISO.txt', 'ISO-8859-1')]"/>
```

## getResourceAsByteArray(String)

Returns the resource from the path String as a byte array.

Example

```xml
 <set-payload
   value="#[MunitTools::getResourceAsByteArray('util/files/example.txt')]"/>
```

## queueSize(String)

Returns the size of the queue specified inside `#[MunitTools::queueSize()]`.

For example, to assert the size of a queue named `QUEUE_SIZE`:

Example

```xml
<munit:execution>
  <munit-tools:queue queueName="QUEUE_SIZE">
    <munit-tools:value>#['EXAMPLE']</munit-tools:value>
  </munit-tools:queue>
</munit:execution>

<munit:validation>
  <munit-tools:assert-that expression="#[MunitTools::queueSize('QUEUE_SIZE')]" is="#[MunitTools::equalTo(1)]"/>
</munit:validation>
```

## createMessage(payload: Any, mimeType: String|Null , attributes: Any, attributeMimeType: String|Null)

Creates a Mule message with the specified attributes.

Example

```xml
<munit:execution>
     <set-payload value="#[MunitTools::createMessage( 'ITEM-1',  'text/plain', { property : 'ATTRIBUTE-1'}, null )]"/>
 </munit:execution>
```

## See Also

- [MUnit Matchers](https://docs.mulesoft.com/munit/latest/munit-matchers)

- [Core Matchers Reference](https://docs.mulesoft.com/munit/latest/core-matchers-reference)

- [String Matchers Reference](https://docs.mulesoft.com/munit/latest/string-matchers-reference)

- [Comparable Matchers Reference](https://docs.mulesoft.com/munit/latest/comparable-matchers-reference)

<!-- document id=d483cdcf00311248181aca7f9eac80c9cee3670dc4022e034b30f6ece18d0fd6 url=/mulesoft/current/en-us/munit/latest/run-custom-event-processor.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
keywords: mule, esb, tests, qa, quality assurance, verify, functional testing, unit testing, stress testing
---

# MUnit Run Custom Event Processor

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The MUnit Run Custom event processor runs a custom Java assertion class against a Mule event during
a MUnit test. Use it when built-in matchers are not sufficient and you need to implement custom
validation logic in Java.

To add the **Run Custom processor** to your project, add the following dependency to your `pom.xml`
file:

```xml
<dependency>
    <groupId>com.mulesoft.munit</groupId>
    <artifactId>munit-assert</artifactId>
    <version>${munit.version}</version>
    <scope>test</scope>
</dependency>
```

You also have to add your custom assertion class to the `mule-artifact.json` file as an exported
resource.

For example, you can define the following assertion in Java:

```java
package org.mule.custom;
import org.mule.munit.assertion.api.MunitAssertion;
import org.mule.munit.assertion.api.TypedValue;

public class CustomAssertion implements MunitAssertion {

    @Override
    public void execute(TypedValue expression, Object params) throws AssertionError { (1)
        if (!"Hello World".equals(expression.getValue())) { (2)
            throw new AssertionError("Error the payload is incorrect");
        }
     }

}
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Implement the only method in the interface <code>public void execute(TypedValue expression, Object params) throws AssertionError</code>.</td></tr><tr><td><i data-value="2"></i><b>2</b></td><td>Run your custom logic, which in this case validates that the message payload is <code>Hello World</code>.</td></tr></tbody></table>

The `CustomAssertion` class must be located in the scr/test/java directory.

And use the **Run Custom Event Processor** to run it:

```xml
<munit-tools:run-custom
  assertion="org.mule.custom.CustomAssertion" (1)
  expression="#[payload]"/>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>The assertion field needs to have the canonical class name of your custom assertion and the class needs to be exported.</td></tr></tbody></table>

To export it when packaging your application, add the `org.mule.custom` package to your
`mule-artifact.json`

```json
{
  "name": "mule-application",
  "minMuleVersion": "4.2.0",
  "classLoaderModelLoaderDescriptor": {
    "id": "mule",
    "attributes": {
      "exportedPackages": ["org.mule.custom"]
    }
  }
}
```

> [!NOTE] You only need to configure the package name in the `exportedPackages` collection.

## See Also

- [MUnit Matchers](https://docs.mulesoft.com/munit/latest/munit-matchers)

- [Assert That Event Processor](https://docs.mulesoft.com/munit/latest/assertion-event-processor)

- [Set Event Processor](https://docs.mulesoft.com/munit/latest/set-event-processor)

- [Mock When Event Processor](https://docs.mulesoft.com/munit/latest/mock-event-processor)

- [Verify Event Processor](https://docs.mulesoft.com/munit/latest/verify-event-processor)

- [Fail Event Processor](https://docs.mulesoft.com/munit/latest/fail-event-processor)

<!-- document id=8d2d31c1e819dc3f7d10407af1ab152321620517f54546d52a98ae76d5aa29c7 url=/mulesoft/current/en-us/munit/latest/set-event-processor.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
keywords: munit, testing, unit testing
---

# MUnit Set Event Processor

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The MUnit Set Event processor defines the initial Mule event, including payload, attributes, and
variables that a MUnit test sends to the flow under test. Use it at the beginning of an MUnit test
to set up the input conditions for your flow.

The example below shows how to define a simple payload of a Mule Message:

```xml
<munit:set-event cloneOriginalEvent="false">
  <munit:payload value="#['payload_value']" mediaType="text/plain" encoding="UTF-8"/>
</munit:set-event>
```

The set-event has the cloneOriginalEvent property. If set to true, it clones the event produced by
your code.  
By default, the value of this property is false.

The payload element in the Set Event processor has the following attributes:

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>value</code></p></td><td><p>Defines the value of the payload’s message.</p></td></tr><tr><td><p><code>encoding</code></p></td><td><p>Defines the encoding of the message. This attribute is optional.</p></td></tr><tr><td><p><code>mediaType</code></p></td><td><p>Defines the mime type of the message. This attribute is optional.</p></td></tr></tbody></table>

You can also use the Set Event processor to define message attributes and event variables:

```xml
<munit:set-event cloneOriginalEvent="false">
  <munit:payload value="#['Example Body']" mediaType="text/plain" encoding="UTF-8"/>

  <munit:attributes value="#[{ method : 'GET', queryParams : { page : '1'}}]" />

  <munit:variables>
    <munit:variable key="variable_key" value="#['example']" mediaType="text/plain" encoding="UTF-8"/>
  </munit:variables>
</munit:set-event>
```

All the properties have the same set of attributes:

<table><caption>Table 1. Property Message Processor’s Attributes</caption> <colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>key</code></p></td><td><p>The key of the property being set.</p></td></tr><tr><td><p><code>value</code></p></td><td><p>The content of the property.</p></td></tr><tr><td><p><code>encoding</code></p></td><td><p>Defines the encoding of the message. This attribute is optional.</p></td></tr><tr><td><p><code>mediaType</code></p></td><td><p>Defines the mime type of the message. This attribute is optional.</p></td></tr></tbody></table>

You can define as many properties per each scope as you need for your test.

> [!WARNING] If you define two properties in the same scope with the _same_ key, be aware that one
> would end up overwriting the other.

## See Also

- [Testing and Mocking Errors](https://docs.mulesoft.com/munit/latest/test-mock-errors-cookbook)

- [Fail Event Processor](https://docs.mulesoft.com/munit/latest/fail-event-processor)

- [Run Custom Event Processor](https://docs.mulesoft.com/munit/latest/run-custom-event-processor)

<!-- document id=ef3e176a37427dc78f6e6d6b3f53a27101ed0bd5973104d742f170d80e23fe76 url=/mulesoft/current/en-us/munit/latest/sleep-processor.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit Sleep Processor

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The MUnit Sleep processor pauses a MUnit test for a specified duration, simulating processing delays
in the flow under test. Use it to test time-dependent behavior or introduce controlled waits between
test steps.

```xml
<munit-tools:sleep time="100" timeUnit="MILLISECONDS"/>
```

`time`

Numerical value for the unit of time that your test waits before going to sleep.

`timeUnit`

The unit in which the `time` value is measured.

Possible values are:

- `MILLISECONDS` (default)

- `MICROSECONDS`

- `MINUTES`

- `NANOSECONDS`

- `SECONDS`

- `HOURS`

<!-- document id=dccb0a062f1f9da47f4b5aae5d2545b77b86e74ddef67c47483d3f0d0bf2bc63 url=/mulesoft/current/en-us/munit/latest/spy-event-processor.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
keywords: munit, testing, unit testing
---

# MUnit Spy Event Processor

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The MUnit Spy event processor observes a specified event processor during a MUnit test, running
assertions or verifications before and after the processor executes without modifying the original
Mule event. Use it to validate the state of the event at specific points in a flow.

Assume that you have this configuration:

```xml
<flow name="testFlow">
  <http:request path="/my/api" />
</flow>
```

You can configure the spy processor to spy on any Http Request and assert that the payload is null
before reaching the component, and not null after it’s been processed:

```xml
<munit:test name="suiteTest" >

  <munit:behavior >

    <munit-tools:spy processor="http:request">
      <munit-tools:before-call >
        <munit-tools:assert-that expression="#[payload]" is="#[MunitTools::nullValue()]"/>
      </munit-tools:before-call>
      <munit-tools:after-call >
        <munit-tools:assert-that expression="#[payload]" is="#[MunitTools::notNullValue()]"/>
      </munit-tools:after-call>
    </munit-tools:spy>

  </munit:behavior>

</munit:test>
```

Or even to spy on any Http Request, whose path is '/my/api'.

```xml
<munit:test name="suiteTest" >

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

  <munit:behavior >

    <munit-tools:spy processor="http:request">
      <munit-tools:with-attributes >
        <munit-tools:with-attribute attributeName="path" whereValue="#['/my/api']" />
      </munit-tools:with-attributes>

      <munit-tools:before-call >
        <munit-tools:assert-that expression="#[payload]" is="#[MunitTools::nullValue()]"/>
      </munit-tools:before-call>

      <munit-tools:after-call >
        <munit-tools:assert-that expression="#[payload]" is="#[MunitTools::notNullValue()]"/>
      </munit-tools:after-call>

    </munit-tools:spy>

  </munit:behavior>

</munit:test>
```

As shown above, this processor enables you to define actions for before and after calling the spied
processor. However, keep in mind that the spy processor does not modify the original Mule Event.  
If you set variables, attributes, or modify the payload inside a Spy, these changes won’t persist
outside the processor.  
Overall, you should use the Spy processor to verify or assert.

## See Also

- [MUnit Event Processors](https://docs.mulesoft.com/munit/latest/event-processors)

<!-- document id=62059c7947d62d3bad644124f75f8d1f84f92679ab25f5cef86776c7657409b9 url=/mulesoft/current/en-us/munit/latest/storage-event-processors.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit Storage Event Processors

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

MUnit Storage event processors manage temporary key-value storage during a MUnit test, letting you
store, retrieve, and remove data across test steps. All stored data is cleared automatically when
each test ends.

## Store Operation

Stores the given data associated with the given key. If `value` not set, it defaults to the
`payload`.

```xml
<munit-tools:store key="myKey">
    <munit-tools:value>#[person : { name: 'John', lastName: 'Smith' }]</munit-tools:value>
</munit-tools:store>
```

## Retrieve Operation

Retrieves the data associated with the given key

```xml
<munit-tools:retrieve key="myKey"/>
```

## Remove Operation

Removes and returns the data associated with the given key

```xml
<munit-tools:remove key="myKey"/>
```

## Clear Stored Data Operation

Clears all stored data

```xml
<munit-tools:clear-stored-data/>
```

<!-- document id=34440cdcc436e2b2f313f4c3588f8877f44502fd64865ec86179cd1002bc359c url=/mulesoft/current/en-us/munit/latest/string-matchers-reference.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit String Matchers Reference

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

MUnit String matchers are matcher functions for asserting conditions on String expressions during a
MUnit test. Use them with the Assert That processor to check for substrings, prefixes, suffixes,
empty values, and case-insensitive equality.

## containsString(String)

Checks that the expression contains the specified String.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::containsString('example')]"/>
```

## startsWith(String)

Checks that the expression starts with the specified String.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::startsWith('exam')]"/>
```

## endsWith(String)

Checks that the expression ends with the specified String.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::endsWith('ple')]"/>
```

## isEmptyString()

Checks that the expression has zero length.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::isEmptyString()]"/>
```

## isEmptyOrNullString()

Checks that the expression is null, or has zero length.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::isEmptyOrNullString()]"/>
```

## equalToIgnoringCase(String)

Checks that the expression is equal to the specified String, ignoring case.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::equalToIgnoringCase('example')]"/>
```

## equalToIgnoringWhiteSpace(String)

Checks that the expression is equal to the string disregarding leading and trailing white spaces,
and compression all inner white spaces to a single space.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::equalToIgnoringWhiteSpace('An Example')]"/>
```

## stringContainsInOrder(Array<String>)

Checks that the expression contains all of the specified substrings, regardless of the order of
their appearance.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::stringContainsInOrder(['an', 'example'])]"/>
```

## See Also

- [MUnit Matchers](https://docs.mulesoft.com/munit/latest/munit-matchers)

- [Core Matchers Reference](https://docs.mulesoft.com/munit/latest/core-matchers-reference)

- [Comparable Matchers Reference](https://docs.mulesoft.com/munit/latest/comparable-matchers-reference)

- [Iterable and Map Matchers Reference](https://docs.mulesoft.com/munit/latest/iterable-map-matchers-reference)

<!-- document id=86e54b88e70395ea473cf91e302c514a8bf75556785eb7b0bb46190ec442475b url=/mulesoft/current/en-us/munit/2.3/munit-domain-support.md -->

---
product: MUnit
version: 2.3
---

# MUnit Support for Domain-Based Applications

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

MUnit allows you to test applications that run referencing a Mule Domain.  
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:

- When working in Anypoint Studio, your Mule Domain must always be part of your workspace.

- Your Folder must have the same name as your artifact.  
  Regardless if it’s a Mule application or a Mule domain if, the folder in your workspace containing
  your Mule project must have the same name as the artifact ID defined in your pom file.

  For example, if your mule project’s artifact Id is:

  ```xml
  <artifactId>mule-project</artifactId>
  ```

  Then, the folder in your Studio workspace must be named `mule-project`.  
  This is case sensitive. If your folder is named `Mule-Project`, MUnit won’t recognize your
  project.

- Your resources need to be installed in an M2 repository.  
  You need to handle domains and mule apps as regular dependencies. Setting them as an artifact
  requires for them to be installed in an .M2 repository.

- Your resources need to be in your test suite pom file.

  If your Mule domain project looks like this:

  ```xml
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.mule.app</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:

  ```xml
  <dependency>
      <groupId>org.mule.app</groupId>
      <artifactId>domain-project</artifactId>
      <version>1.0.0-SNAPSHOT</version>
      <classifier>mule-domain</classifier>
      <scope>provided</scope>
  </dependency>
  ```

  > [!TIP] Remember to keep consistency with `<version>` artifact in your repository and in your
  > test suite’s pom file

## See Also

- [Domain Support (Anypoint Studio)](https://docs.mulesoft.com/studio/domain-support-concept)

<!-- document id=82c045832ec1d921235c5456af63557f1704fb1214ecce3155ad236b8ef48ce4 url=/mulesoft/current/en-us/munit/3.6/munit-domain-support.md -->

---
product: MUnit
version: 3.6
---

# MUnit Support for Domain-Based Applications

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

MUnit allows you to test applications that run referencing a Mule Domain.  
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:

- When working in Anypoint Studio, your Mule Domain must always be part of your workspace.

- Your Folder must have the same name as your artifact.  
  Regardless if it’s a Mule application or a Mule domain if, the folder in your workspace containing
  your Mule project must have the same name as the artifact ID defined in your pom file.

  For example, if your mule project’s artifact Id is:

  ```xml
  <artifactId>mule-project</artifactId>
  ```

  Then, the folder in your Studio workspace must be named `mule-project`.  
  This is case sensitive. If your folder is named `Mule-Project`, MUnit won’t recognize your
  project.

- Your resources need to be installed in an M2 repository.  
  You need to handle domains and mule apps as regular dependencies. Setting them as an artifact
  requires for them to be installed in an .M2 repository.

- Your resources need to be in your test suite pom file.

  If your Mule domain project looks like this:

  ```xml
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.mule.app</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:

  ```xml
  <dependency>
      <groupId>org.mule.app</groupId>
      <artifactId>domain-project</artifactId>
      <version>1.0.0-SNAPSHOT</version>
      <classifier>mule-domain</classifier>
      <scope>provided</scope>
  </dependency>
  ```

  > [!TIP] Remember to keep consistency with `<version>` artifact in your repository and in your
  > test suite’s pom file

## See Also

- [Domain Support (Anypoint Studio)](https://docs.mulesoft.com/studio/domain-support-concept)

<!-- document id=f32326c58d1352e8ed5973f7c7ff2d7210f90d52f35fe2e3633754e5765feeaa url=/mulesoft/current/en-us/munit/latest/munit-domain-support.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit Support for Domain-Based Applications

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

MUnit supports testing Mule applications that reference a Mule domain, with minimal code changes
required. Before running domain-based tests, ensure your domain is in your workspace, folder names
match artifact IDs, and domain resources are installed in your M2 repository.

- When working in Anypoint Studio, your Mule Domain must always be part of your workspace.

- Your Folder must have the same name as your artifact.  
  Regardless if it’s a Mule application or a Mule domain if, the folder in your workspace containing
  your Mule project must have the same name as the artifact ID defined in your pom file.

  For example, if your mule project’s artifact Id is:

  ```xml
  <artifactId>mule-project</artifactId>
  ```

  Then, the folder in your Studio workspace must be named `mule-project`.  
  This is case sensitive. If your folder is named `Mule-Project`, MUnit won’t recognize your
  project.

- Your resources need to be installed in an M2 repository.  
  You need to handle domains and mule apps as regular dependencies. Setting them as an artifact
  requires for them to be installed in an .M2 repository.

- Your resources need to be in your test suite pom file.

  If your Mule domain project looks like this:

  ```xml
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.mule.app</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:

  ```xml
  <dependency>
      <groupId>org.mule.app</groupId>
      <artifactId>domain-project</artifactId>
      <version>1.0.0-SNAPSHOT</version>
      <classifier>mule-domain</classifier>
      <scope>provided</scope>
  </dependency>
  ```

  > [!TIP] Remember to keep consistency with `<version>` artifact in your repository and in your
  > test suite’s pom file

## See Also

- [Domain Support (Anypoint Studio)](https://docs.mulesoft.com/studio/domain-support-concept)

<!-- document id=9cb91b74e30148143a06043f36d066c86364f14ba4cf4bd831664e448de67443 url=/mulesoft/current/en-us/munit/latest/test-recorder.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit Test Recorder in Anypoint Studio

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

The MUnit Test Recorder captures real flow execution data in Anypoint Studio and automatically
generates an MUnit test with configured mocks and assertions. Use it to quickly create tests based
on actual application behavior without writing test code from scratch. See
[Record an MUnit Test from an Anypoint Exchange Example](https://docs.mulesoft.com/munit/latest/test-recorder-examples) for a fully working
example.

## Compatibility

The following table describes the product versions required to use the Test Recorder.

<table><colgroup><col> <col></colgroup><thead><tr><th>Product</th><th>Version</th></tr></thead><tbody><tr><td><div><div><p>Anypoint Studio</p></div></div></td><td><div><div><p>7.5.0 and later</p></div></div></td></tr><tr><td><div><div><p>MUnit</p></div></div></td><td><div><div><p>2.2.5 and later</p></div></div></td></tr><tr><td><div><div><p>MUnit Anypoint Studio Plugin</p></div></div></td><td><div><div><p>2.5.0 and later</p></div></div></td></tr><tr><td><div><div><p>Mule runtime engine</p></div></div></td><td><div><div><p>4.3.0 and later</p></div></div></td></tr></tbody></table>

## Limitations

The test recorder has the following limitations when you create MUnit tests:

- You cannot create tests for flows with Mule errors raised inside the flow or already existing in
  the incoming event, even if an **on error continue** error handler controls them.

- A recorded flow execution ends successfully, but the result does not reach its destination because
  the application is killed.

- Your validations fail every time your test runs if you configure `spy` or `assert` processors to
  assert values for random data, time-dependent information (such as timestamps), or values
  resulting from parallel processes, because those values change in every execution.

- Mocking values resulting from parallel processes causes a mixture of real and mocked data that
  compromises the execution of the processors that follow in your test.

- Although the recorder supports data iteration in the flow, such as recursions or loops, it does
  not support cases in which the structure of the data being tested changes inside the iteration.

- The recorder does not support mocking a message before or inside a `foreach` processor.

- When using the Test Recorder to generate a test over your flow, you can only mock parameters
  included in your flow. You cannot mock parameters in sub-flows or in referenced flows through the
  Test Recorder UI. If you need to mock parameters in sub-flows of any other process in the project,
  you can modify the mocking component after creating the test.

## See Also

- [Record an MUnit Test from an Anypoint Exchange Example](https://docs.mulesoft.com/munit/latest/test-recorder-examples)

- [Mock Messages Before and Inside a Foreach Processor in MUnit](https://docs.mulesoft.com/munit/latest/mock-before-after-foreach-cookbook)

<!-- document id=479c2fa5ade05d99902c10c4afa2ea1717fa3eb96347f1043aaf7ef7ad124c91 url=/mulesoft/current/en-us/munit/2.3/munit-test-concept.md -->

---
product: MUnit
version: 2.3
---

# MUnit Test Structure Fundamentals

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

## MUnit Test Suite

The base file in MUnit is the test suite file, an XML file located in the `src/test/munit` directory
of your Mule application project. You can have as many MUnit test suite files as you need. Each
MUnit test suite file is a collection of MUnit tests, and runs independently from other MUnit test
suites.

An MUnit test suite can contain any combination of the following components:

- Before/After Suites

- Before/After Tests

- MUnit tests

Each MUnit test suite is, behind the scenes, no different than a Mule configuration file. You can
use several of the Mule top level elements such as flow, sub-flow, and scripts.

### MUnit Configuration

The MUnit configuration element (`munit:config`) identifies a Mule configuration file as an MUnit
suite file:

```xml
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:munit="http://www.mulesoft.org/schema/mule/munit" xmlns:munit-tools="http://www.mulesoft.org/schema/mule/munit-tools"
	xmlns="http://www.mulesoft.org/schema/mule/core"
	xsi:schemaLocation="
		http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
		http://www.mulesoft.org/schema/mule/munit http://www.mulesoft.org/schema/mule/munit/current/mule-munit.xsd
		http://www.mulesoft.org/schema/mule/munit-tools  http://www.mulesoft.org/schema/mule/munit-tools/current/mule-munit-tools.xsd">

	<munit:config name="An MUnit Suite" />

	<!-- Tests -->

</mule>
```

#### Ignore a Suite

To ignore a whole suite from running, you can use the `ignore` attribute of the configuration:

```xml
<munit:config name="A MUnit Suite" ignore="true"/>
```

#### Minimum Mule Version

To specify that a suite should run if the Mule version that is equal or newer than a specific
version, use the `minMuleVersion` attribute of the configuration:

```xml
<munit:config name="A MUnit Suite" minMuleVersion="4.1.4"/>
```

## MUnit Test

An MUnit test is the basic processor of an MUnit test suite. It represents each test scenario you
want to try.

The MUnit test is divided in three scopes:

<table><colgroup><col> <col></colgroup><thead><tr><th>Scope</th><th>Description</th></tr></thead><tbody><tr><td><p>Behavior</p></td><td><p>The behavior scope sets all the preconditions before executing the test logic.</p></td></tr><tr><td><p>Execution</p></td><td><p>The execution scope contains the testing logic which waits for all processes to finish before executing the next scope.</p></td></tr><tr><td><p>Validation</p></td><td><p>The validation scope contains all the validations for the results of the execution scope.</p></td></tr></tbody></table>

These scopes are optional.

```xml
<munit:test name="exampleTest" description="Test to verify scenario 1">>

     <munit:behavior>
         <!-- Processors to set preconditions for the test -->
     </munit:behavior>

     <munit:execution>
         <flow-ref name="exampleFlow"/>
     </munit:execution>

     <munit:validation>
         <!-- Processors to validate result -->
     </munit:validation>
 </munit:test>
```

![munit-test](/mulesoft/current/en-us/munit/2.3/_images/munit-test-concept-9c736.png)

Figure 1. A Studio representation of the MUnit Test

### MUnit Test Reference

<table><colgroup><col> <col></colgroup><thead><tr><th>Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>name</code></p></td><td><p>Defines the name of the test. The name must be unique inside the test suite.<br>This attribute is mandatory.</p></td></tr><tr><td><p><code>description</code></p></td><td><p>Describes the scenario being tested.</p></td></tr><tr><td><p><code>ignore</code></p></td><td><p>Defines if the test should be ignored. If not present, the test is not ignored.</p></td></tr><tr><td><p><code>tags</code></p></td><td><p>Comma separated list of tags to assign to the test.</p></td></tr><tr><td><p><code>expectedErrorType</code></p></td><td><p>Defines the error Type that should be received after the execution of this test.</p></td></tr><tr><td><p><code>expectedException</code></p></td><td><p>Defines the exception that should be received after the execution of this test.</p></td></tr><tr><td><p><code>expectedErrorDescription</code></p></td><td><p>Defines the error description that should be received after the execution of this test.</p></td></tr><tr><td><p><code>timeOut</code></p></td><td><p>Defines maximum time in milliseconds that the test can run before failing.</p></td></tr></tbody></table>

#### MUnit Test Description Attribute

In MUnit, you must write a description for your test. Ideally, you should write a useful,
representative description of the scenario you are testing. This description displays in the test
console before running the test, and also in the reports. The more representative the description,
the easier to read and troubleshoot any failures.

#### Ignore a Test

There may be scenarios where you need to shut down a test. Whether this be because the test is
failing or because it has inconvenient side effects. MUnit allows you to ignore a specific test so
that you don’t have to manually comment out the code.

You can ignore any of your tests by adding the ignore boolean to the test definition:

```xml
<munit:test name="my-flow-Test"
      ignore="true"
      description="Test to verify scenario 1">
</munit:test>
```

The default value for the ignore attribute is `false`.

In Anypoint Studio, you can check the **Ignore Test** option.

![ignore-test](/mulesoft/current/en-us/munit/2.3/_images/munit-test-concept-de4c9.png)

You can also use expressions to ignore a test based on your current mule version or on your current
operating system:

Ignore a Test Based on Operating System

```xml
<munit:test name="linux-ignore-test" ignore="#[Munit::osEqualTo('Mac OS X')]">
```

Ignore a Test Based on Mule Runtime Engine Version

```xml
<munit:test name="mule-version-ignore-test" ignore="#[Munit::muleVersionPriorTo('4.1.4')]">
```

This test will be ignored if the Mule version is prior to `4.1.4`. Other possible functions are
`muleVersionEqualTo` and `muleVersionNewerThan`.

#### Test TimeOut Attribute

Each MUnit test automatically fails if it takes more than 2 minutes to complete. Use the `timeOut`
attribute to set a custom maximum time --in milliseconds-- that the test can run before failing:

```xml
<munit:test
  name="custom-timeout-test"
  description="This test has a timeout of 10 seconds"
  timeOut="10000" >
  ....
</munit:test>
```

#### Test Tag Attribute

MUnit allows you to tag your tests, so you can choose to run tests under a specific tag. For
example:

```xml
<munit:test
  name="exampleTest"
  description="A test that works as an example"
  ignore="true"
  tags="integration,http" >
		…
</munit:test>
```

![test-tags](/mulesoft/current/en-us/munit/2.3/_images/munit-test-concept-c2d9f.png)

Figure 2. In Anypoint Studio, you can define tags in the proper field.

#### MUnit Test Expected Error and Exception Attributes

Assume that you want to validate that the flow or sub-flow you are testing fails and throws a
specific error. MUnit allows you to add the attributes `expectedErrorType`, `expectException`, and
`expectedErrorDescription`, as follows:

```xml
<munit:test name="MUnit-test-suite"
  description="A test that works as an example"
  expectedErrorType="RETRY_EXHAUSTED"
  expectedException="java.lang.RuntimeException"
  expectedErrorDescription="retries exhausted">
  ...
</munit:test>
```

![munit test concept e7280](/mulesoft/current/en-us/munit/2.3/_images/munit-test-concept-e7280.png)

Figure 3. A visual representation on Anypoint Studio

- The `expectedErrorType` attribute expects an error ID defined inside the application being
  tested.  
  This attribute allows you to validate that a defined error type in your application is thrown. If
  you define an `errorType` that does not exist in your application, the test does not run.

  ```xml
  <munit:test name="MUnit-test-suite"
    description="Test Error Type"
    expectedErrorType="FTP:ILLEGAL_PATH">
    ...
  </munit:test>
  ```

  This Error Type test expects that an FTP operation will throw an `FTP:ILLEGAL_PATH` error.  
  If none of your flows are using an FTP connector, then the error type is not defined within your
  application and the test will not run.

  ErrorTypes that belong to the Mule Runtime do not need to be typified. For example,
  `MULE:RETRY_EXHAUSTED` can be defined as simply `RETRY_EXHAUSTED`.

- The attribute `expectException` expects a literal exception class name.  
  You must provide the canonical class name of the exception that you expect. MUnit then validates
  that the underlying cause for the exception thrown is of the exact same type of the class name you
  are expecting.

  ```xml
  <munit:test name="testExceptions"
    description="Test Exceptions"
    expectedException="java.lang.RuntimeException">
    ...
  </munit:test>
  ```

  If you define that your test expects an exception and none is thrown, the test fails immediately.

- The attribute expectedErrorDescription expects an error description.  
  This attribute allows you to validate that an error is thrown and this error has description that
  is equals or contains the expected error description. If you define that your test expects an
  error and none is thrown or the error thrown description doesn’t match, the test fails
  immediately.

  ```xml
  <munit:test name="testExpectedErrorDescription"
    description="Test Expected Error Description Attribute"
    expectedErrorDescription="An error has occurred">
    ...
  </munit:test>
  ```

## Before and After Scopes

As with other testing frameworks, MUnit provides a set of scopes that allow you to add processing or
actions to run before and/or after the entire MUnit test or MUnit test suite execute:

- Before and After Suite Scopes.

- Before and After Test Scopes.

The ID field for each component must be unique across all your application. The before and after
scopes cannot share the same name between them, nor have the same name as any flow in your
application.

See [Before/After scopes](https://docs.mulesoft.com/munit/2.3/before-after-scopes-reference) reference for more information.

<!-- document id=b69ae2b2fb5eec567f841f5c5a5649bbdecea217d7b3db9961630a9c0194fe10 url=/mulesoft/current/en-us/munit/3.6/munit-test-concept.md -->

---
product: MUnit
version: 3.6
---

# MUnit Test Structure Fundamentals

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

## MUnit Test Suite

The base file in MUnit is the test suite file, an XML file located in the `src/test/munit` directory
of your Mule application project. You can use multiple MUnit test suite files. Each MUnit test suite
file is a collection of MUnit tests and runs independently from other MUnit test suites.

An MUnit test suite can contain any combination of the following components:

- Before/After Suites

- Before/After Tests

- MUnit tests

Each MUnit test suite is similar to a Mule configuration file. You can use several of the Mule
top-level elements such as flow, sub-flow, and scripts.

### MUnit Configuration

The MUnit configuration element (`munit:config`) identifies a Mule configuration file as an MUnit
suite file:

```xml
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:munit="http://www.mulesoft.org/schema/mule/munit" xmlns:munit-tools="http://www.mulesoft.org/schema/mule/munit-tools"
	xmlns="http://www.mulesoft.org/schema/mule/core"
	xsi:schemaLocation="
		http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
		http://www.mulesoft.org/schema/mule/munit http://www.mulesoft.org/schema/mule/munit/current/mule-munit.xsd
		http://www.mulesoft.org/schema/mule/munit-tools  http://www.mulesoft.org/schema/mule/munit-tools/current/mule-munit-tools.xsd">

	<munit:config name="An MUnit Suite" />

	<!-- Tests -->

</mule>
```

#### Ignore a Suite

To ignore a whole suite from running, you can use the `ignore` attribute of the configuration:

```xml
<munit:config name="A MUnit Suite" ignore="true"/>
```

#### Minimum Mule Version

Specify the minimum required Mule version to run a test suite by defining the `minMuleVersion`
attribute of the configuration:

```xml
<munit:config name="A MUnit Suite" minMuleVersion="4.1.4"/>
```

## MUnit Test

An MUnit test is the basic processor of an MUnit test suite and it represents the scenario to test.

Three optional scopes divide MUnit tests:

<table><colgroup><col> <col></colgroup><thead><tr><th>Scope</th><th>Description</th></tr></thead><tbody><tr><td><p>Behavior</p></td><td><p>The behavior scope sets all the preconditions before executing the test logic.</p></td></tr><tr><td><p>Execution</p></td><td><p>The execution scope contains the testing logic which waits for all processes to finish before executing the next scope.</p></td></tr><tr><td><p>Validation</p></td><td><p>The validation scope contains all the validations for the results of the execution scope.</p></td></tr></tbody></table>

```xml
<munit:test name="exampleTest" description="Test to verify scenario 1">>

     <munit:behavior>
         <!-- Processors to set preconditions for the test -->
     </munit:behavior>

     <munit:execution>
         <flow-ref name="exampleFlow"/>
     </munit:execution>

     <munit:validation>
         <!-- Processors to validate result -->
     </munit:validation>
 </munit:test>
```

![munit-test](/mulesoft/current/en-us/munit/3.6/_images/munit-test-concept-9c736.png)

Figure 1. A Studio representation of the MUnit Test

### MUnit Test Reference

<table><colgroup><col> <col></colgroup><thead><tr><th>Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>name</code></p></td><td><p>Defines the name of the test. The name must be unique in the test suite.<br>This attribute is mandatory.</p></td></tr><tr><td><p><code>description</code></p></td><td><p>Describes the scenario to test.</p></td></tr><tr><td><p><code>ignore</code></p></td><td><p>Defines if the test must be ignored. If not present, the test isn’t ignored.</p></td></tr><tr><td><p><code>tags</code></p></td><td><p>Comma-separated list of tags to assign to the test.</p></td></tr><tr><td><p><code>expectedErrorType</code></p></td><td><p>Defines the error Type to receive after executing the test.</p></td></tr><tr><td><p><code>expectedException</code></p></td><td><p>Defines the exception to receive after executing the test.</p></td></tr><tr><td><p><code>expectedErrorDescription</code></p></td><td><p>Defines the error description to receive after executing the test.</p></td></tr><tr><td><p><code>timeOut</code></p></td><td><p>Defines the maximum time in milliseconds that the test can run before failing.</p></td></tr></tbody></table>

#### MUnit Test Description Attribute

MUnit tests require a description. The description must be useful and representative of the tested
scenario. This description shows in the test console before running the test, and also in the
reports. The more representative the description, the easier it is to read and troubleshoot
failures.

#### Ignore a Test

When a test fails or has inconvenient side effects, you can shut it down without commenting out the
code.

To ignore a test, add the `ignore` boolean to its definition:

```xml
<munit:test name="my-flow-Test"
      ignore="true"
      description="Test to verify scenario 1">
</munit:test>
```

The default value for the ignore attribute is `false`.

You can also use expressions to ignore a test based on your current Mule version or on your current
operating system:

Ignore a Test Based on the Operating System

```xml
<munit:test name="linux-ignore-test" ignore="#[Munit::osEqualTo('Mac OS X')]">
```

Ignore a Test Based on Mule Runtime Engine Version

```xml
<munit:test name="mule-version-ignore-test" ignore="#[Munit::muleVersionPriorTo('4.1.4')]">
```

MUnit ignores this test if the Mule version is earlier than `4.1.4`. Other possible functions are
`muleVersionEqualTo` and `muleVersionNewerThan`.

#### Test TimeOut Attribute

An MUnit test automatically fails if it takes more than 2 minutes to complete. Use the `timeOut`
attribute to set a custom maximum time --in milliseconds-- that the test can run before failing:

```xml
<munit:test
  name="custom-timeout-test"
  description="This test has a timeout of 10 seconds"
  timeOut="10000" >
  ....
</munit:test>
```

#### Test Tag Attribute

You can tag your tests and choose to run tests under a specific tag. For example:

```xml
<munit:test
  name="exampleTest"
  description="A test that works as an example"
  ignore="true"
  tags="integration,http" >
		…
</munit:test>
```

![Tags field highlighted in Studio.](/mulesoft/current/en-us/munit/3.6/_images/munit-test-concept-c2d9f.png)

Figure 2. In Anypoint Studio, you can define tags in the **Tags** field.

#### MUnit Test Expected Error and Exception Attributes

To validate that a flow or sub-flow you’re testing fails and throws a specific error, add the
`expectedErrorType`, `expectException`, and `expectedErrorDescription` attributes as follows:

```xml
<munit:test name="MUnit-test-suite"
  description="A test that works as an example"
  expectedErrorType="RETRY_EXHAUSTED"
  expectedException="java.lang.RuntimeException"
  expectedErrorDescription="retries exhausted">
  ...
</munit:test>
```

![Failure Expectation section highlighted in Studio.](/mulesoft/current/en-us/munit/3.6/_images/munit-test-concept-e7280.png)

Figure 3. A visual representation on Anypoint Studio

- The `expectedErrorType` attribute expects an error ID defined in the tested application.  
  This attribute validates that your application throws a defined error type. If you define an
  `errorType` that does not exist in your application, the test doesn’t run.

  ```xml
  <munit:test name="MUnit-test-suite"
    description="Test Error Type"
    expectedErrorType="FTP:ILLEGAL_PATH">
    ...
  </munit:test>
  ```

  This Error Type test expects that an FTP operation throws an `FTP:ILLEGAL_PATH` error.  
  If none of your flows are using an FTP connector, then the error type isn’t defined within your
  application and the test doesn’t run.

  You mustn’t typify `ErrorTypes` that belong to the Mule Runtime. For example, you can define
  `MULE:RETRY_EXHAUSTED` as `RETRY_EXHAUSTED`.

- The attribute `expectException` expects a literal exception class name.  
  You must provide the canonical class name of the exception that you expect. MUnit then validates
  that the underlying cause for the exception thrown is of the same type of the class name you’re
  expecting.

  ```xml
  <munit:test name="testExceptions"
    description="Test Exceptions"
    expectedException="java.lang.RuntimeException">
    ...
  </munit:test>
  ```

  If you define that your test expects an exception and none is thrown, the test fails immediately.

- The attribute `expectedErrorDescription` expects an error description.  
  This attribute validates that your application throws an error and the error has a description
  that is equal to or contains the expected error description. If you define that your test expects
  an error and none is thrown or the error description doesn’t match, the test fails immediately.

  ```xml
  <munit:test name="testExpectedErrorDescription"
    description="Test Expected Error Description Attribute"
    expectedErrorDescription="An error has occurred">
    ...
  </munit:test>
  ```

## Before and After Scopes

As with other testing frameworks, MUnit provides a set of scopes so you can add processing or
actions to run before and after the entire MUnit test or MUnit test suite executes:

- Before and After Suite Scopes.

- Before and After Test Scopes.

The ID field for each component must be unique across all your applications. The before and after
scopes can’t share the same name, nor have the same name as any flow in your application.

See [Before and After Scopes](https://docs.mulesoft.com/munit/3.6/before-after-scopes-reference) reference for additional information.

<!-- document id=1cba535e075840a67b42a3c1266d6c244e736ae6782f0f40c67fe15862367767 url=/mulesoft/current/en-us/munit/latest/munit-test-concept.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit Test Structure Fundamentals

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

An MUnit test suite is an XML file that contains MUnit tests organized into behavior, execution, and
validation scopes. Use test suite files in the src/test/munit directory to define, configure, and
run automated tests against your Mule application flows.

## MUnit Test Suite

The base file in MUnit is the test suite file, an XML file located in the `src/test/munit` directory
of your Mule application project. You can use multiple MUnit test suite files. Each MUnit test suite
file is a collection of MUnit tests and runs independently from other MUnit test suites.

An MUnit test suite can contain any combination of the following components:

- Before/After Suites

- Before/After Tests

- MUnit tests

Each MUnit test suite is similar to a Mule configuration file. You can use several of the Mule
top-level elements such as flow, sub-flow, and scripts.

### MUnit Configuration

The MUnit configuration element (`munit:config`) identifies a Mule configuration file as an MUnit
suite file:

```xml
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:munit="http://www.mulesoft.org/schema/mule/munit" xmlns:munit-tools="http://www.mulesoft.org/schema/mule/munit-tools"
	xmlns="http://www.mulesoft.org/schema/mule/core"
	xsi:schemaLocation="
		http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
		http://www.mulesoft.org/schema/mule/munit http://www.mulesoft.org/schema/mule/munit/current/mule-munit.xsd
		http://www.mulesoft.org/schema/mule/munit-tools  http://www.mulesoft.org/schema/mule/munit-tools/current/mule-munit-tools.xsd">

	<munit:config name="An MUnit Suite" />

	<!-- Tests -->

</mule>
```

#### Ignore a Suite

To ignore a whole suite from running, you can use the `ignore` attribute of the configuration:

```xml
<munit:config name="A MUnit Suite" ignore="true"/>
```

#### Minimum Mule Version

Specify the minimum required Mule version to run a test suite by defining the `minMuleVersion`
attribute of the configuration:

```xml
<munit:config name="A MUnit Suite" minMuleVersion="4.1.4"/>
```

## MUnit Test

An MUnit test is the basic processor of an MUnit test suite and it represents the scenario to test.

Three optional scopes divide MUnit tests:

<table><colgroup><col> <col></colgroup><thead><tr><th>Scope</th><th>Description</th></tr></thead><tbody><tr><td><p>Behavior</p></td><td><p>The behavior scope sets all the preconditions before executing the test logic.</p></td></tr><tr><td><p>Execution</p></td><td><p>The execution scope contains the testing logic which waits for all processes to finish before executing the next scope.</p></td></tr><tr><td><p>Validation</p></td><td><p>The validation scope contains all the validations for the results of the execution scope.</p></td></tr></tbody></table>

```xml
<munit:test name="exampleTest" description="Test to verify scenario 1">>

     <munit:behavior>
         <!-- Processors to set preconditions for the test -->
     </munit:behavior>

     <munit:execution>
         <flow-ref name="exampleFlow"/>
     </munit:execution>

     <munit:validation>
         <!-- Processors to validate result -->
     </munit:validation>
 </munit:test>
```

![munit-test](/mulesoft/current/en-us/munit/latest/_images/munit-test-concept-9c736.png)

Figure 1. A Studio representation of the MUnit Test

### MUnit Test Reference

<table><colgroup><col> <col></colgroup><thead><tr><th>Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>name</code></p></td><td><p>Defines the name of the test. The name must be unique in the test suite.<br>This attribute is mandatory.</p></td></tr><tr><td><p><code>description</code></p></td><td><p>Describes the scenario to test.</p></td></tr><tr><td><p><code>ignore</code></p></td><td><p>Defines if the test must be ignored. If not present, the test isn’t ignored.</p></td></tr><tr><td><p><code>tags</code></p></td><td><p>Comma-separated list of tags to assign to the test.</p></td></tr><tr><td><p><code>expectedErrorType</code></p></td><td><p>Defines the error Type to receive after executing the test.</p></td></tr><tr><td><p><code>expectedException</code></p></td><td><p>Defines the exception to receive after executing the test.</p></td></tr><tr><td><p><code>expectedErrorDescription</code></p></td><td><p>Defines the error description to receive after executing the test.</p></td></tr><tr><td><p><code>timeOut</code></p></td><td><p>Defines the maximum time in milliseconds that the test can run before failing.</p></td></tr></tbody></table>

#### MUnit Test Description Attribute

MUnit tests require a description. The description must be useful and representative of the tested
scenario. This description shows in the test console before running the test, and also in the
reports. The more representative the description, the easier it is to read and troubleshoot
failures.

#### Ignore a Test

When a test fails or has inconvenient side effects, you can shut it down without commenting out the
code.

To ignore a test, add the `ignore` boolean to its definition:

```xml
<munit:test name="my-flow-Test"
      ignore="true"
      description="Test to verify scenario 1">
</munit:test>
```

The default value for the ignore attribute is `false`.

You can also use expressions to ignore a test based on your current Mule version or on your current
operating system:

Ignore a Test Based on the Operating System

```xml
<munit:test name="linux-ignore-test" ignore="#[Munit::osEqualTo('Mac OS X')]">
```

Ignore a Test Based on Mule Runtime Engine Version

```xml
<munit:test name="mule-version-ignore-test" ignore="#[Munit::muleVersionPriorTo('4.1.4')]">
```

MUnit ignores this test if the Mule version is earlier than `4.1.4`. Other possible functions are
`muleVersionEqualTo` and `muleVersionNewerThan`.

#### Test Timeout Attribute

An MUnit test automatically fails if it takes more than 2 minutes to complete. Use the `timeOut`
attribute to set a custom maximum time --in milliseconds-- that the test can run before failing:

```xml
<munit:test
  name="custom-timeout-test"
  description="This test has a timeout of 10 seconds"
  timeOut="10000" >
  ....
</munit:test>
```

#### Test Tag Attribute

You can tag your tests and choose to run tests under a specific tag. For example:

```xml
<munit:test
  name="exampleTest"
  description="A test that works as an example"
  ignore="true"
  tags="integration,http" >
		…
</munit:test>
```

![Tags field highlighted in Studio.](/mulesoft/current/en-us/munit/latest/_images/munit-test-concept-c2d9f.png)

Figure 2. In Anypoint Studio, you can define tags in the **Tags** field.

#### MUnit Test Expected Error and Exception Attributes

To validate that a flow or sub-flow you’re testing fails and throws a specific error, add the
`expectedErrorType`, `expectException`, and `expectedErrorDescription` attributes as follows:

```xml
<munit:test name="MUnit-test-suite"
  description="A test that works as an example"
  expectedErrorType="RETRY_EXHAUSTED"
  expectedException="java.lang.RuntimeException"
  expectedErrorDescription="retries exhausted">
  ...
</munit:test>
```

![Failure Expectation section highlighted in Studio.](/mulesoft/current/en-us/munit/latest/_images/munit-test-concept-e7280.png)

Figure 3. A visual representation on Anypoint Studio

- The `expectedErrorType` attribute expects an error ID defined in the tested application.  
  This attribute validates that your application throws a defined error type. If you define an
  `errorType` that does not exist in your application, the test doesn’t run.

  ```xml
  <munit:test name="MUnit-test-suite"
    description="Test Error Type"
    expectedErrorType="FTP:ILLEGAL_PATH">
    ...
  </munit:test>
  ```

  This Error Type test expects that an FTP operation throws an `FTP:ILLEGAL_PATH` error.  
  If none of your flows are using an FTP connector, then the error type isn’t defined within your
  application and the test doesn’t run.

  You mustn’t typify `ErrorTypes` that belong to the Mule Runtime. For example, you can define
  `MULE:RETRY_EXHAUSTED` as `RETRY_EXHAUSTED`.

- The attribute `expectException` expects a literal exception class name.  
  You must provide the canonical class name of the exception that you expect. MUnit then validates
  that the underlying cause for the exception thrown is of the same type of the class name you’re
  expecting.

  ```xml
  <munit:test name="testExceptions"
    description="Test Exceptions"
    expectedException="java.lang.RuntimeException">
    ...
  </munit:test>
  ```

  If you define that your test expects an exception and none is thrown, the test fails immediately.

- The attribute `expectedErrorDescription` expects an error description.  
  This attribute validates that your application throws an error and the error has a description
  that is equal to or contains the expected error description. If you define that your test expects
  an error and none is thrown or the error description doesn’t match, the test fails immediately.

  ```xml
  <munit:test name="testExpectedErrorDescription"
    description="Test Expected Error Description Attribute"
    expectedErrorDescription="An error has occurred">
    ...
  </munit:test>
  ```

## Before and After Scopes

As with other testing frameworks, MUnit provides a set of scopes so you can add processing or
actions to run before and after the entire MUnit test or MUnit test suite executes:

- Before and After Suite Scopes.

- Before and After Test Scopes.

The ID field for each component must be unique across all your applications. The before and after
scopes can’t share the same name, nor have the same name as any flow in your application.

See [MUnit Before and After Scopes](https://docs.mulesoft.com/munit/latest/before-after-scopes-reference) reference for additional
information.

<!-- document id=7daa5177a283c3fe991400faac1e57f3ce45733ad8a103bf4e3b8531260280d5 url=/mulesoft/current/en-us/munit/2.3/munit-utils.md -->

---
product: MUnit
version: 2.3
---

# MUnit Utils

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

One of the main problems of testing production code are external system connections.

MUnit provides a set of utilities for you to write your tests in a portable way and mock external
system connections from your tests.

<table><colgroup><col> <col></colgroup><thead><tr><th>Utility</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/2.3/db-util">Database</a></p></div></div></td><td><div><div><p>Implement a DB server in your local environment to test connections.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/2.3/ftp-util">FTP</a></p></div></div></td><td><div><div><p>Implement an FTP server in your local environment to test connections.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/2.3/queue-processors">Queue Event Processors</a></p></div></div></td><td><div><div><p>Manage temporary queues during your test runs.</p></div></div></td></tr></tbody></table>

<!-- document id=ce5e61da6afa2ef78e55f1572d3ca6bb0e7cabbc5fee5bdca1d288ea042cf127 url=/mulesoft/current/en-us/munit/3.6/munit-utils.md -->

---
product: MUnit
version: 3.6
---

# MUnit Utils

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

One of the main problems of testing production code are external system connections.

MUnit provides a set of utilities for you to write your tests in a portable way and mock external
system connections from your tests.

<table><colgroup><col> <col></colgroup><thead><tr><th>Utility</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/3.6/db-util">Database</a></p></div></div></td><td><div><div><p>Implement a DB server in your local environment to test connections.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/3.6/ftp-util">FTP</a></p></div></div></td><td><div><div><p>Implement an FTP server in your local environment to test connections.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/3.6/queue-processors">Queue Event Processors</a></p></div></div></td><td><div><div><p>Manage temporary queues during your test runs.</p></div></div></td></tr></tbody></table>

<!-- document id=19edd114e5448f566bf2d43cf21d76805586e1a3435b9123c7f6d0687e53e48c url=/mulesoft/current/en-us/munit/latest/munit-utils.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# MUnit Utils

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

MUnit Utils are utilities that let you mock external system connections in MUnit tests, making your
test suites portable and independent from external infrastructure. Use them to implement in-memory
database and FTP servers, or manage temporary queues during test runs.

<table><colgroup><col> <col></colgroup><thead><tr><th>Utility</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/latest/db-util">Install the MUnit Database Server Module</a></p></div></div></td><td><div><div><p>Implement a DB server in your local environment to test connections.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/latest/ftp-util">Install the MUnit FTP Server Module</a></p></div></div></td><td><div><div><p>Implement an FTP server in your local environment to test connections.</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/munit/latest/queue-processors">Queue Event Processors</a></p></div></div></td><td><div><div><p>Manage temporary queues during your test runs.</p></div></div></td></tr></tbody></table>

<!-- document id=ec1be745c7b9459ecd1082e9b8cf1c9dd599cea9f8403b7244e3425c72a6655b url=/mulesoft/current/en-us/munit/latest/verify-event-processor.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
keywords: munit, testing, unit testing
---

# MUnit Verify Event Processor

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The MUnit Verify event processor validates that a specified event processor was called a certain
number of times during a MUnit test. Use it to confirm that your flow executed the expected
processors with the expected attributes, even without creating a mock for them.

```xml
<munit-tools:verify-call processor="http:request" atLeast="1">
   <munit-tools:with-attributes>
       <munit-tools:with-attribute attributeName="method" whereValue="#['GET']" />
   </munit-tools:with-attributes>
</munit-tools:verify-call>
```

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>eventProcessor</code></p></td><td><p>Describes which event processor you want to mock. The description takes the form <code>{name-space}:{event-processor-name}</code>. It supports regular expressions.</p></td></tr><tr><td><p><code>times</code></p></td><td><p><strong>(Default = 1.)</strong> Defines the verification as successful if the event processor was called <em>N</em> and only <em>N</em> number of times.</p></td></tr><tr><td><p><code>atLeast</code></p></td><td><p>Defines the verification as successful if the event processor was called a minimum of <em>N</em> number of times.</p></td></tr><tr><td><p><code>atMost</code></p></td><td><p>Defines the verification as successful if the event processor was called maximum of <em>N</em> number of times.</p></td></tr></tbody></table>

The attributes `times`, `atLeast`, `atMost`, are mutually exclusive.

The `eventProcessor` attribute accepts regular expressions. For example, you can create the same
verification as `.*:request` to verify for an event processor named request, disregarding which
namespace the event processor belongs to. The regular expression language is the same as Java.

## See Also

- [Assert That Event Processor](https://docs.mulesoft.com/munit/latest/assertion-event-processor)

- [Fail Event Processor](https://docs.mulesoft.com/munit/latest/fail-event-processor)

- [Run Custom Event Processor](https://docs.mulesoft.com/munit/latest/run-custom-event-processor)

- [Set Event Processor](https://docs.mulesoft.com/munit/latest/set-event-processor)

- [Mock When Event Processor](https://docs.mulesoft.com/munit/latest/mock-event-processor)

<!-- document id=8fd6fe9da69e4005f7e69c2ce5ecdca8f44ac4b4505d578e94c8ac67baccbde9 url=/mulesoft/current/en-us/munit/2.3/index.md -->

---
product: MUnit
version: 2.3
---

# Overview

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

MUnit is a Mule application testing framework that allows you to easily build automated tests for
your integrations and APIs. It provides a full suite of integration and unit test capabilities, and
is fully integrated with Maven and Surefire for integration with your continuous deployment
environment.

MUnit version 2.3, works with all Mule versions since 4.0

With MUnit you can:

- Create your test by writing Mule code

- Mock processors

- Spy any processor

- Verify processor calls

- Enable or ignore particular tests

- Tag tests

- Check visual coverage in Studio

- Generate coverage reports

MUnit is fully integrated with Anypoint Studio, allowing you to create, design and run MUnit tests
just like you would Mule applications.

MUnit is divided in two main sub modules:

- MUnit

- MUnit Tools

Each module has its own dependency:

MUnit Dependencies

```xml
<dependency>
	<groupId>com.mulesoft.munit</groupId>
	<artifactId>munit-runner</artifactId>
	<version>2.3.0</version>
	<classifier>mule-plugin</classifier>
	<scope>test</scope>
</dependency>
```

MUnit Tools dependencies

```xml
<dependency>
	<groupId>com.mulesoft.munit</groupId>
	<artifactId>munit-tools</artifactId>
	<version>2.3.0</version>
	<classifier>mule-plugin</classifier>
	<scope>test</scope>
</dependency>
```

## See Also

- [MUnit Event Processors](https://docs.mulesoft.com/munit/2.3/event-processors)

<!-- document id=fdaff98e7732e317077ca7e3d027c39247a347a9533f33af75acee7b8d5d9c83 url=/mulesoft/current/en-us/munit/2.3/parameterized.md -->

---
product: MUnit
version: 2.3
keywords: munit, testing, unit testing
---

# Parameterized

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

A parameterized test suite runs the same tests but with different inputs.

The test suite parameterization is defined at a configuration level as follows:

```xml
<munit:config>
    <munit:parameterizations>
        <munit:parameterization name="firstParameterization">
            <munit:parameters>
                <munit:parameter propertyName="name" value="Robert"/>
                <munit:parameter propertyName="lastname" value="Plant"/>
            </munit:parameters>
        </munit:parameterization>
        <munit:parameterization name="secondParameterization">
            <munit:parameters>
                <munit:parameter propertyName="name" value="Jimmy"/>
                <munit:parameter propertyName="lastname" value="Page"/>
            </munit:parameters>
        </munit:parameterization>
    </munit:parameterizations>
</munit:config>
```

The Test Suite runs twice: Firstly, with the `firstParameterization` parameters. Secondly, with the
`secondParameterization` parameters.

For example, if you have a test that sets a payload for a flow and expects a result:

Parameterization Example

```xml
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns="http://www.mulesoft.org/schema/mule/core"
      xmlns:munit="http://www.mulesoft.org/schema/mule/munit"
      xmlns:munit-tools="http://www.mulesoft.org/schema/mule/munit-tools"
      xsi:schemaLocation="
        http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
        http://www.mulesoft.org/schema/mule/munit http://www.mulesoft.org/schema/mule/munit/current/mule-munit.xsd
        http://www.mulesoft.org/schema/mule/munit-tools http://www.mulesoft.org/schema/mule/munit-tools/current/mule-munit-tools.xsd">

    <munit:config name="parameterized-test.xml">
        <munit:parameterizations>
            <munit:parameterization name="sumThree">
                <munit:parameters>
                    <munit:parameter propertyName="input" value="#[1]"/>
                    <munit:parameter propertyName="output" value="#[2]"/>
                </munit:parameters>
            </munit:parameterization>
            <munit:parameterization name="sumFive">
                <munit:parameters>
                    <munit:parameter propertyName="input" value="#[2]"/>
                    <munit:parameter propertyName="output" value="#[4]"/>
                </munit:parameters>
            </munit:parameterization>
        </munit:parameterizations>
    </munit:config>

    <munit:test name="expectFlowResult">
        <munit:behavior>
            <set-payload value="${input}"/>
        </munit:behavior>
        <munit:execution >
            <flow-ref name="myFlow"/>
        </munit:execution>
        <munit:validation>
            <munit-tools:assert-equals actual="#[payload]" expected="${output}" />
        </munit:validation>
    </munit:test>

</mule>
```

## Parameterization from File

To use the same parameterized values on different test suites, you must save your parameterizations
values in a YAML file in the `/test/resources` directory of your Mule application project:

parameterizations.yaml Example

```yaml
firstParameterization:
  name: "Robert"
  lastname: "Plant"

secondParameterization:
  name: "Jimmy"
  lastname: "Page"
```

And reference it from your test suite configuration:

Example Parameterization From File

```xml
<munit:config>
    <munit:parameterizations file="parameterizations.yaml" />
</munit:config>
```

You can combine both methods to add parameterized values to a test suite:

Example Parameterization From File and in the Test Suite Configuration

```xml
<munit:config name="parameterization-from-file-test.xml">
    <munit:parameterizations file="parameterizations.yaml" >
        <munit:parameterization name="thirdParameterization">
            <munit:parameters>
                <munit:parameter propertyName="name" value="John"/>
                <munit:parameter propertyName="lastname" value="Bonham"/>
            </munit:parameters>
        </munit:parameterization>
    </munit:parameterizations>
</munit:config>
```

If you define the same parameterization key in a YAML file and your test suite configuration, the
test suite parameterization overrides your YAML parameterization.

<!-- document id=a8dac889f2b197cd22052b394b386ab04a523c529b676f4e5e28f66e5acff89a url=/mulesoft/current/en-us/munit/3.6/parameterized.md -->

---
product: MUnit
version: 3.6
keywords: munit, testing, unit testing
---

# Parameterized

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

A parameterized test suite runs the same tests but with different inputs.

The test suite parameterization is defined at a configuration level as follows:

```xml
<munit:config>
    <munit:parameterizations>
        <munit:parameterization name="firstParameterization">
            <munit:parameters>
                <munit:parameter propertyName="name" value="Robert"/>
                <munit:parameter propertyName="lastname" value="Plant"/>
            </munit:parameters>
        </munit:parameterization>
        <munit:parameterization name="secondParameterization">
            <munit:parameters>
                <munit:parameter propertyName="name" value="Jimmy"/>
                <munit:parameter propertyName="lastname" value="Page"/>
            </munit:parameters>
        </munit:parameterization>
    </munit:parameterizations>
</munit:config>
```

The Test Suite runs twice: Firstly, with the `firstParameterization` parameters. Secondly, with the
`secondParameterization` parameters.

For example, if you have a test that sets a payload for a flow and expects a result:

Parameterization Example

```xml
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns="http://www.mulesoft.org/schema/mule/core"
      xmlns:munit="http://www.mulesoft.org/schema/mule/munit"
      xmlns:munit-tools="http://www.mulesoft.org/schema/mule/munit-tools"
      xsi:schemaLocation="
        http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
        http://www.mulesoft.org/schema/mule/munit http://www.mulesoft.org/schema/mule/munit/current/mule-munit.xsd
        http://www.mulesoft.org/schema/mule/munit-tools http://www.mulesoft.org/schema/mule/munit-tools/current/mule-munit-tools.xsd">

    <munit:config name="parameterized-test.xml">
        <munit:parameterizations>
            <munit:parameterization name="sumThree">
                <munit:parameters>
                    <munit:parameter propertyName="input" value="#[1]"/>
                    <munit:parameter propertyName="output" value="#[2]"/>
                </munit:parameters>
            </munit:parameterization>
            <munit:parameterization name="sumFive">
                <munit:parameters>
                    <munit:parameter propertyName="input" value="#[2]"/>
                    <munit:parameter propertyName="output" value="#[4]"/>
                </munit:parameters>
            </munit:parameterization>
        </munit:parameterizations>
    </munit:config>

    <munit:test name="expectFlowResult">
        <munit:behavior>
            <set-payload value="${input}"/>
        </munit:behavior>
        <munit:execution >
            <flow-ref name="myFlow"/>
        </munit:execution>
        <munit:validation>
            <munit-tools:assert-equals actual="#[payload]" expected="${output}" />
        </munit:validation>
    </munit:test>

</mule>
```

## Parameterization from File

To use the same parameterized values on different test suites, you must save your parameterizations
values in a YAML file in the `/test/resources` directory of your Mule application project:

parameterizations.yaml Example

```yaml
firstParameterization:
  name: "Robert"
  lastname: "Plant"

secondParameterization:
  name: "Jimmy"
  lastname: "Page"
```

And reference it from your test suite configuration:

Example Parameterization From File

```xml
<munit:config>
    <munit:parameterizations file="parameterizations.yaml" />
</munit:config>
```

You can combine both methods to add parameterized values to a test suite:

Example Parameterization From File and in the Test Suite Configuration

```xml
<munit:config name="parameterization-from-file-test.xml">
    <munit:parameterizations file="parameterizations.yaml" >
        <munit:parameterization name="thirdParameterization">
            <munit:parameters>
                <munit:parameter propertyName="name" value="John"/>
                <munit:parameter propertyName="lastname" value="Bonham"/>
            </munit:parameters>
        </munit:parameterization>
    </munit:parameterizations>
</munit:config>
```

If you define the same parameterization key in a YAML file and your test suite configuration, the
test suite parameterization overrides your YAML parameterization.

<!-- document id=551eed38bc8f74194f354a76e3b1939e20f8760973b3b47e1b5bf7116b170031 url=/mulesoft/current/en-us/munit/latest/runtime-patching.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# Patch the Embedded Mule Runtime Engine Version in MUnit

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

Patch the embedded Mule runtime engine version that MUnit uses to run tests, overriding the default
version defined in your `mule-artifact.json` file. You can configure the patched version from Maven
or Anypoint Studio.

## Patch MUnit Using Maven

By default, MUnit runs against the Mule version corresponding to the `minMuleVersion` defined in the
`mule-artifact.json` file. You can override this version by using the `munit.runtimeversion`
property in the `munit-maven-plugin` artifact configuration:

```xml
<plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <version>${munit.version}</version>
    <executions>
        <execution>
            <id>test</id>
            <phase>test</phase>
            <goals>
                <goal>test</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
      <munit.runtimeversion>4.3.0-20200727</munit.runtimeversion> (1)
    </configuration>
</plugin>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Be sure to replace the placeholder version in this example with your version, as provided by MuleSoft.</td></tr></tbody></table>

The `munit.runtimeversion` property replaces the deprecated `runtimeVersion` property. The
`runtimeVersion` property remains supported for backward compatibility. If you use `runtimeVersion`,
MUnit displays a warning message that indicates the property is deprecated and that you must migrate
to `munit.runtimeversion`.

## Patch MUnit Using Studio

By default, MUnit runs in Anypoint Studio with the Mule runtime engine version of the project
server. You can override this version by specifying the patched Mule version in the MUnit run
configuration menu:

1.  In the menu bar, select **Run** and **Run Configurations**.

2.  Under **MUnit**, select your MUnit test file.

3.  In the **Mule Runtime Version** field under **Advanced Settings**, type the Mule patched version
    to use.

    ![Patched Mule runtime version used for the test.](/mulesoft/current/en-us/munit/latest/_images/runtime-patching-studio.png)

If you already set the `munit.runtimeversion` property in the POM file of your project, click **Load
configuration from POM file** to automatically load this version into the **Mule Runtime Version**
field.

## See Also

- [Mule Runtime Release Notes](https://docs.mulesoft.com/release-notes/mule-runtime/mule-esb)

- [MUnit Maven Plugin](https://docs.mulesoft.com/munit/latest/munit-maven-plugin)

<!-- document id=cab1468bad79f1fb1e96acdcb3346a1e600b5e40c87d339d3678ac7db0ce8ddc url=/mulesoft/current/en-us/munit/2.3/runtime-patching.md -->

---
product: MUnit
version: 2.3
---

# Patching the Embedded Mule Runtime Engine Version

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

Patching in MUnit is different from patching in Mule runtime engine. MUnit runs using an embedded
Mule container, which downloads all required dependencies to start Mule based on a given version. To
use a patched Mule version (for example, `4.3.0-20200727`), you must point MUnit to run specifically
against it. You can do this from either Maven or Anypoint Studio.

## Patch MUnit Using Maven

By default, MUnit runs against the Mule version corresponding to the `minMuleVersion` defined in the
`mule-artifact.json` file. You can override this version by using the `runtimeVersion` attribute of
the `munit-maven-plugin` artifact configuration:

```xml
<plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <version>${munit.version}</version>
    <executions>
        <execution>
            <id>test</id>
            <phase>test</phase>
            <goals>
                <goal>test</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
      <runtimeVersion>4.3.0-20200727</runtimeVersion> (1)
    </configuration>
</plugin>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Be sure to replace the placeholder version in this example with your version, as provided by MuleSoft.</td></tr></tbody></table>

## Patch MUnit Using Studio

By default, MUnit runs in Anypoint Studio with the Mule runtime engine version of the project
server. You can override this version by specifying the patched Mule version in the MUnit run
configuration menu:

1.  In the top menu bar, select **Run** and **Run Configurations…**.

2.  Under **MUnit**, select your MUnit test file.

3.  In the **Mule Runtime Version** field under **Advanced Settings** type the Mule patched version
    you want to use.

    ![runtime patching studio](/mulesoft/current/en-us/munit/2.3/_images/runtime-patching-studio.png)

If you already set the `runtimeVersion` attribute in the POM file of your project, click **Load
configuration from POM file** to automatically load this version into the **Mule Runtime Version**
field.

## See Also

- [Mule Runtime Release Notes](https://docs.mulesoft.com/release-notes/mule-runtime/mule-esb)

- [MUnit Maven Plugin](https://docs.mulesoft.com/munit/2.3/munit-maven-plugin)

<!-- document id=5b4c62d6416df3cda4f7061c380dcb900222470b970426b7ef4ed313c3a94880 url=/mulesoft/current/en-us/munit/3.6/runtime-patching.md -->

---
product: MUnit
version: 3.6
---

# Patching the Embedded Mule Runtime Engine Version

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

Patching in MUnit is different from patching in Mule runtime engine. MUnit runs using an embedded
Mule container, which downloads all required dependencies to start Mule based on a given version. To
use a patched Mule version (for example, `4.3.0-20200727`), you must point MUnit to run specifically
against it. You can do this from either Maven or Anypoint Studio.

## Patch MUnit Using Maven

By default, MUnit runs against the Mule version corresponding to the `minMuleVersion` defined in the
`mule-artifact.json` file. You can override this version by using the `runtimeVersion` attribute of
the `munit-maven-plugin` artifact configuration:

```xml
<plugin>
    <groupId>com.mulesoft.munit.tools</groupId>
    <artifactId>munit-maven-plugin</artifactId>
    <version>${munit.version}</version>
    <executions>
        <execution>
            <id>test</id>
            <phase>test</phase>
            <goals>
                <goal>test</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
      <runtimeVersion>4.3.0-20200727</runtimeVersion> (1)
    </configuration>
</plugin>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Be sure to replace the placeholder version in this example with your version, as provided by MuleSoft.</td></tr></tbody></table>

## Patch MUnit Using Studio

By default, MUnit runs in Anypoint Studio with the Mule runtime engine version of the project
server. You can override this version by specifying the patched Mule version in the MUnit run
configuration menu:

1.  In the menu bar, select **Run** and **Run Configurations**.

2.  Under **MUnit**, select your MUnit test file.

3.  In the **Mule Runtime Version** field under **Advanced Settings**, type the Mule patched version
    to use.

    ![Patched Mule runtime version used for the test.](/mulesoft/current/en-us/munit/3.6/_images/runtime-patching-studio.png)

If you already set the `runtimeVersion` attribute in the POM file of your project, click **Load
configuration from POM file** to automatically load this version into the **Mule Runtime Version**
field.

## See Also

- [Mule Runtime Release Notes](https://docs.mulesoft.com/release-notes/mule-runtime/mule-esb)

- [MUnit Maven Plugin](https://docs.mulesoft.com/munit/3.6/munit-maven-plugin)

<!-- document id=c496178517affa37b4466ad02786286ba7a128787960f41e764e112fc2b6a4c7 url=/mulesoft/current/en-us/munit/2.3/queue-processors.md -->

---
product: MUnit
version: 2.3
keywords: munit, testing, unit testing, queue
---

# Queue Event Processors

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

The Queue event processors allow you to manage temporary queues during your test runs.

All queues are emptied as soon as the test ends.

## Queue

Adds the value to the queue. If not specified, the value is taken from the `payload`.

```xml
<munit-tools:queue>
    <munit-tools:value>#[1]</munit-tools:value>
</munit-tools:queue>
```

You can specify the queue’s name to which the value should be added. If not specified, the default
queue will be used.

```xml
<munit-tools:queue queueName="CUSTOM_QUEUE_1">
    <munit-tools:value>#[1]</munit-tools:value>
</munit-tools:queue>
```

## Dequeue

Removes the last element of the queue, if the queue is empty, it waits until an element is queued.

```xml
<munit-tools:dequeue/>
```

You can specify a timeout when waiting for an element to be queued:

```xml
<munit-tools:dequeue timeout="1000" timeoutUnit="SECONDS"/>
```

Like the queue operation, you can specify the queue’s name from which to dequeue. If not specified,
the default queue will be used.

```xml
<munit-tools:dequeue queueName="CUSTOM_QUEUE_1"/>
```

## Queue Size

Function that obtains the queue size.

```xml
<munit-tools:assert-that expression="#[MunitTools::queueSize()]" is="#[MunitTools::equalTo(2)]" />
```

Like the other operations, you can specify the queue from which to the get the size. If not
specified, the default queue will be used.

```xml
<munit-tools:assert-that expression="#[MunitTools::queueSize('CUSTOM_QUEUE_1')]" is="#[MunitTools::equalTo(2)]" />
```

<!-- document id=b6e3c1b971b8a66f348aaab6553ded17c90433712bb48e859874d7e774c10bfd url=/mulesoft/current/en-us/munit/3.6/queue-processors.md -->

---
product: MUnit
version: 3.6
keywords: munit, testing, unit testing, queue
---

# Queue Event Processors

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The Queue event processors allow you to manage temporary queues during your test runs.

All queues are emptied as soon as the test ends.

## Queue

Adds the value to the queue. If not specified, the value is taken from the `payload`.

```xml
<munit-tools:queue>
    <munit-tools:value>#[1]</munit-tools:value>
</munit-tools:queue>
```

You can specify the queue’s name to which the value should be added. If not specified, the default
queue will be used.

```xml
<munit-tools:queue queueName="CUSTOM_QUEUE_1">
    <munit-tools:value>#[1]</munit-tools:value>
</munit-tools:queue>
```

## Dequeue

Removes the last element of the queue, if the queue is empty, it waits until an element is queued.

```xml
<munit-tools:dequeue/>
```

You can specify a timeout when waiting for an element to be queued:

```xml
<munit-tools:dequeue timeout="1000" timeoutUnit="SECONDS"/>
```

Like the queue operation, you can specify the queue’s name from which to dequeue. If not specified,
the default queue will be used.

```xml
<munit-tools:dequeue queueName="CUSTOM_QUEUE_1"/>
```

## Queue Size

Function that obtains the queue size.

```xml
<munit-tools:assert-that expression="#[MunitTools::queueSize()]" is="#[MunitTools::equalTo(2)]" />
```

Like the other operations, you can specify the queue from which to the get the size. If not
specified, the default queue will be used.

```xml
<munit-tools:assert-that expression="#[MunitTools::queueSize('CUSTOM_QUEUE_1')]" is="#[MunitTools::equalTo(2)]" />
```

<!-- document id=0880ab9d9af19bc0ab32e78cbb041e3403cb72f58a16193eadea70d4dbf0aaa7 url=/mulesoft/current/en-us/munit/2.3/munit-showing-results.md -->

---
product: MUnit
version: 2.3
---

# Reading MUnit Results

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

This section briefly explains how to read the MUnit console logs.

Successful Build

```console
============================================================
============  Running  new-test-suite.xml suite ============
============================================================
++++++++++++++++++++++++++++++++++++++++++++
+ Running test: test-suite - Test          +
++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ SUCCESS - Test test-suite finished successfully - Time elapsed: 2227ms +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

==================================================================================
Number of tests run: 1 - Failed: 0 - Errors: 0 - Skipped: 0 - Time elapsed: 2241ms
==================================================================================

[INFO] ====================================================================================
[INFO] MUnit Run Summary
[INFO] ====================================================================================
[INFO]  >> new-test-suite.xml test result: Tests: 1, Errors: 0, Failures: 0, Skipped: 0
[NOTE]
[INFO] ====================================================================================
[INFO]  > Tests:   	1
[INFO]  > Errors:  	0
[INFO]  > Failures:	0
[INFO]  > Skipped: 	0
[INFO] ====================================================================================
```

Failed Build

```console
============================================================
============  Running  new-test-suite.xml suite ============
============================================================
++++++++++++++++++++++++++++++++++++++++++++
+ Running test: test-suite - Test          +
++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ FAILURE - The test test-suite finished with a failure - Time elapsed: 2399ms +
java.lang.AssertionError:
Expected: "Bye World!"
     but: was "Hello World"
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.mule.munit.assertion.internal.AssertModule.assertThat(AssertModule.java:34)
	at org.mule.munit.tools.assertion.AssertOperations.assertThat(AssertOperations.java:45)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

==================================================================================
Number of tests run: 1 - Failed: 1 - Errors: 0 - Skipped: 0 - Time elapsed: 2416ms
==================================================================================

[INFO] ====================================================================================
[INFO] MUnit Run Summary
[INFO] ====================================================================================
[INFO]  >> new-test-suite.xml test result: Tests: 1, Errors: 0, Failures: 1, Skipped: 0
[INFO] 	 --- test-suite <<< FAILED
[NOTE]
[INFO] ====================================================================================
[INFO]  > Tests:   	1
[INFO]  > Errors:  	0
[INFO]  > Failures:	1
[INFO]  > Skipped: 	0
[INFO] ====================================================================================
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 22.400 s
[INFO] Finished at: 2017-11-16T14:37:32-03:00
[INFO] Final Memory: 19M/302M
[INFO] ------------------------------------------------------------------------
```

Build Error

```console
============================================================
============  Running  new-test-suite.xml suite ============
============================================================
++++++++++++++++++++++++++++++++++++++++++++
+ Running test: test-suite - Test          +
++++++++++++++++++++++++++++++++++++++++++++
ERROR 2017-11-16 14:40:20,239 [[coverage].http.requester.HTTP_Request_configuration.01: [coverage].http.requester.HTTP_Request_configuration @55ccbf06 SelectorRunner] org.mule.extension.http.internal.request.HttpRequester: Error sending HTTP request to http://0.0.0.0:8081/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ ERROR - The test test-suite finished with an error - Time elapsed: 218ms +
java.util.concurrent.ExecutionException: org.mule.runtime.api.component.execution.ComponentExecutionException: org.mule.extension.http.api.error.HttpRequestFailedException: HTTP GET on resource 'http://0.0.0.0:8081/' failed: Connection refused.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[INFO] ====================================================================================
[INFO] MUnit Run Summary
[INFO] ====================================================================================
[INFO]  >> new-test-suite.xml test result: Tests: 1, Errors: 1, Failures: 0, Skipped: 0
[INFO] 	 --- test-suite <<< ERROR
[NOTE]
[INFO] ====================================================================================
[INFO]  > Tests:   	1
[INFO]  > Errors:  	1
[INFO]  > Failures:	0
[INFO]  > Skipped: 	0
[INFO] ====================================================================================
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 20.167 s
[INFO] Finished at: 2017-11-16T14:40:27-03:00
[INFO] Final Memory: 25M/315M
[INFO] ------------------------------------------------------------------------
```

## See Also

<!-- document id=fba0f9efe029fd88257c51862a8c6322ed007e39278071334adb747ba9f3ce99 url=/mulesoft/current/en-us/munit/3.6/munit-showing-results.md -->

---
product: MUnit
version: 3.6
---

# Reading MUnit Results

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

This section briefly explains how to read the MUnit console logs.

Successful Build

```console
============================================================
============  Running  new-test-suite.xml suite ============
============================================================
++++++++++++++++++++++++++++++++++++++++++++
+ Running test: test-suite - Test          +
++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ SUCCESS - Test test-suite finished successfully - Time elapsed: 2227ms +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

==================================================================================
Number of tests run: 1 - Failed: 0 - Errors: 0 - Skipped: 0 - Time elapsed: 2241ms
==================================================================================

[INFO] ====================================================================================
[INFO] MUnit Run Summary
[INFO] ====================================================================================
[INFO]  >> new-test-suite.xml test result: Tests: 1, Errors: 0, Failures: 0, Skipped: 0
[NOTE]
[INFO] ====================================================================================
[INFO]  > Tests:   	1
[INFO]  > Errors:  	0
[INFO]  > Failures:	0
[INFO]  > Skipped: 	0
[INFO] ====================================================================================
```

Failed Build

```console
============================================================
============  Running  new-test-suite.xml suite ============
============================================================
++++++++++++++++++++++++++++++++++++++++++++
+ Running test: test-suite - Test          +
++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ FAILURE - The test test-suite finished with a failure - Time elapsed: 2399ms +
java.lang.AssertionError:
Expected: "Bye World!"
     but: was "Hello World"
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.mule.munit.assertion.internal.AssertModule.assertThat(AssertModule.java:34)
	at org.mule.munit.tools.assertion.AssertOperations.assertThat(AssertOperations.java:45)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

==================================================================================
Number of tests run: 1 - Failed: 1 - Errors: 0 - Skipped: 0 - Time elapsed: 2416ms
==================================================================================

[INFO] ====================================================================================
[INFO] MUnit Run Summary
[INFO] ====================================================================================
[INFO]  >> new-test-suite.xml test result: Tests: 1, Errors: 0, Failures: 1, Skipped: 0
[INFO] 	 --- test-suite <<< FAILED
[NOTE]
[INFO] ====================================================================================
[INFO]  > Tests:   	1
[INFO]  > Errors:  	0
[INFO]  > Failures:	1
[INFO]  > Skipped: 	0
[INFO] ====================================================================================
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 22.400 s
[INFO] Finished at: 2017-11-16T14:37:32-03:00
[INFO] Final Memory: 19M/302M
[INFO] ------------------------------------------------------------------------
```

Build Error

```console
============================================================
============  Running  new-test-suite.xml suite ============
============================================================
++++++++++++++++++++++++++++++++++++++++++++
+ Running test: test-suite - Test          +
++++++++++++++++++++++++++++++++++++++++++++
ERROR 2017-11-16 14:40:20,239 [[coverage].http.requester.HTTP_Request_configuration.01: [coverage].http.requester.HTTP_Request_configuration @55ccbf06 SelectorRunner] org.mule.extension.http.internal.request.HttpRequester: Error sending HTTP request to http://0.0.0.0:8081/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ ERROR - The test test-suite finished with an error - Time elapsed: 218ms +
java.util.concurrent.ExecutionException: org.mule.runtime.api.component.execution.ComponentExecutionException: org.mule.extension.http.api.error.HttpRequestFailedException: HTTP GET on resource 'http://0.0.0.0:8081/' failed: Connection refused.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[INFO] ====================================================================================
[INFO] MUnit Run Summary
[INFO] ====================================================================================
[INFO]  >> new-test-suite.xml test result: Tests: 1, Errors: 1, Failures: 0, Skipped: 0
[INFO] 	 --- test-suite <<< ERROR
[NOTE]
[INFO] ====================================================================================
[INFO]  > Tests:   	1
[INFO]  > Errors:  	1
[INFO]  > Failures:	0
[INFO]  > Skipped: 	0
[INFO] ====================================================================================
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 20.167 s
[INFO] Finished at: 2017-11-16T14:40:27-03:00
[INFO] Final Memory: 25M/315M
[INFO] ------------------------------------------------------------------------
```

<!-- document id=444b3ab28f3943d26fa04c7e7acf25e74101f5f274b1f89c97d6dd6ceed3e951 url=/mulesoft/current/en-us/munit/latest/munit-showing-results.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# Reading MUnit Results

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

MUnit console logs report test results in three states: successful build, failed build, and build
error. Use the MUnit Run Summary at the end of each run to quickly identify the number of tests,
failures, errors, and skipped tests.

Successful Build

```console
============================================================
============  Running  new-test-suite.xml suite ============
============================================================
++++++++++++++++++++++++++++++++++++++++++++
+ Running test: test-suite - Test          +
++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ SUCCESS - Test test-suite finished successfully - Time elapsed: 2227ms +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

==================================================================================
Number of tests run: 1 - Failed: 0 - Errors: 0 - Skipped: 0 - Time elapsed: 2241ms
==================================================================================

[INFO] ====================================================================================
[INFO] MUnit Run Summary
[INFO] ====================================================================================
[INFO]  >> new-test-suite.xml test result: Tests: 1, Errors: 0, Failures: 0, Skipped: 0
[NOTE]
[INFO] ====================================================================================
[INFO]  > Tests:   	1
[INFO]  > Errors:  	0
[INFO]  > Failures:	0
[INFO]  > Skipped: 	0
[INFO] ====================================================================================
```

Failed Build

```console
============================================================
============  Running  new-test-suite.xml suite ============
============================================================
++++++++++++++++++++++++++++++++++++++++++++
+ Running test: test-suite - Test          +
++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ FAILURE - The test test-suite finished with a failure - Time elapsed: 2399ms +
java.lang.AssertionError:
Expected: "Bye World!"
     but: was "Hello World"
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.mule.munit.assertion.internal.AssertModule.assertThat(AssertModule.java:34)
	at org.mule.munit.tools.assertion.AssertOperations.assertThat(AssertOperations.java:45)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

==================================================================================
Number of tests run: 1 - Failed: 1 - Errors: 0 - Skipped: 0 - Time elapsed: 2416ms
==================================================================================

[INFO] ====================================================================================
[INFO] MUnit Run Summary
[INFO] ====================================================================================
[INFO]  >> new-test-suite.xml test result: Tests: 1, Errors: 0, Failures: 1, Skipped: 0
[INFO] 	 --- test-suite <<< FAILED
[NOTE]
[INFO] ====================================================================================
[INFO]  > Tests:   	1
[INFO]  > Errors:  	0
[INFO]  > Failures:	1
[INFO]  > Skipped: 	0
[INFO] ====================================================================================
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 22.400 s
[INFO] Finished at: 2017-11-16T14:37:32-03:00
[INFO] Final Memory: 19M/302M
[INFO] ------------------------------------------------------------------------
```

Build Error

```console
============================================================
============  Running  new-test-suite.xml suite ============
============================================================
++++++++++++++++++++++++++++++++++++++++++++
+ Running test: test-suite - Test          +
++++++++++++++++++++++++++++++++++++++++++++
ERROR 2017-11-16 14:40:20,239 [[coverage].http.requester.HTTP_Request_configuration.01: [coverage].http.requester.HTTP_Request_configuration @55ccbf06 SelectorRunner] org.mule.extension.http.internal.request.HttpRequester: Error sending HTTP request to http://0.0.0.0:8081/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ ERROR - The test test-suite finished with an error - Time elapsed: 218ms +
java.util.concurrent.ExecutionException: org.mule.runtime.api.component.execution.ComponentExecutionException: org.mule.extension.http.api.error.HttpRequestFailedException: HTTP GET on resource 'http://0.0.0.0:8081/' failed: Connection refused.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[INFO] ====================================================================================
[INFO] MUnit Run Summary
[INFO] ====================================================================================
[INFO]  >> new-test-suite.xml test result: Tests: 1, Errors: 1, Failures: 0, Skipped: 0
[INFO] 	 --- test-suite <<< ERROR
[NOTE]
[INFO] ====================================================================================
[INFO]  > Tests:   	1
[INFO]  > Errors:  	1
[INFO]  > Failures:	0
[INFO]  > Skipped: 	0
[INFO] ====================================================================================
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 20.167 s
[INFO] Finished at: 2017-11-16T14:40:27-03:00
[INFO] Final Memory: 25M/315M
[INFO] ------------------------------------------------------------------------
```

<!-- document id=25892831d0d96ec5ab6f998c93bc54a6b25eb55563b1691603d3bf313509a902 url=/mulesoft/current/en-us/munit/latest/test-recorder-examples.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# Record an MUnit Test from an Anypoint Exchange Example

> 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

Record an MUnit test in Anypoint Studio by importing an existing project from Anypoint Exchange and
capturing flow processing with the MUnit test recorder. This example uses the Login Form Using the
HTTP Connector project.

## Prerequisite

- Your Anypoint Platform credentials are configured in Studio.  
  See [Configuring Anypoint Platform Credentials](https://docs.mulesoft.com/studio/set-credentials-in-studio-to) for
  more information.

## Test the Login Form Using the HTTP Connector Example

1.  Click the Open Exchange icon ![3%](/mulesoft/current/en-us/munit/latest/_images/exchange-icon.png).

2.  Select **Provided by MuleSoft** in the pop-up Exchange window, filter per **Examples**, and look
    for the **Login Form Using the HTTP Connector**.

3.  Click **Open**.  
    Studio imports the example as a new working project.

4.  If prompted, select **Perform Update** in **Update your Workspace**.

5.  Select the Manage Mule Projects APIs icon ![2%](/mulesoft/current/en-us/munit/latest/_images/manage-project-api-icon.png).

6.  Select **Modules** and update both **MUnit** and **Munit Tools**:

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

7.  Select **Apply and Close**.

### Test the Process for a Successful Login Attempt

1.  In your project, right-click `DoLoginFlow` and select **Munit** > **Record new test for this
    flow**:

    ![login flow test recorder example](/mulesoft/current/en-us/munit/latest/_images/login-flow-test-recorder-example.png)

    The test recorder starts your project and starts recording the event going through that flow.

2.  Open a browser and navigate to `http://0.0.0.0:8081/login`.

3.  Type `mule` for both **Username** and **Password**, and click **Submit**.

    The test recorder captures this event and stops the recording.

4.  Return to Studio and click **Configure Test**:

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

5.  Select the file name for the MUnit test suite in which you want to record your test.

6.  Under **Test name**, type `_DoLoginFlow-successfull_`.

7.  Set the test recorder to set the recorded input of the flow, and assert that the recorded output
    is the expected output by the test.

8.  In **Successful login**, select **Verify that this process was called** and set the counter
    **equal to** to `_1_` time.

9.  Click **Next** and then **Finish**.

    A fully functional MUnit test is generated to assert that the process in your application works
    as expected when the login is successful.

### Test the Process for an Unsuccessful Login Attempt

1.  In your project, right-click `DoLoginFlow` and select **Munit** > **Record new test for this
    flow**:

    ![login flow test recorder example](/mulesoft/current/en-us/munit/latest/_images/login-flow-test-recorder-example.png)

    The test recorder starts your project and starts recording the event going through that flow.

2.  Open a browser and navigate to `http://0.0.0.0:8081/login`.

3.  Type `admin` in both **Username** and **Password**, and click **Submit**:

    The test recorder captures this event and stops the recording.

4.  Return to Studio and click **Configure Test**:

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

5.  Select the file name for the MUnit test suite in which you want to record your test.

6.  Under **Test name**, type `_DoLoginFlow-unsuccessfull_`.

7.  Set the test recorder to set the recorded input of the flow, and assert that the recorded output
    is the expected output by the test.

8.  In the **Unsuccessful login** parse template step, select **Verify that this process was
    called** and set the counter to **equal to** `_1_` time.

9.  Click **Next** and then **Finish**.

    A fully functional MUnit test is generated to assert that the process in your application works
    as expected when the login fails.

## See Also

- [Test Recorder in Studio](https://docs.mulesoft.com/munit/latest/test-recorder)

<!-- document id=827ce81609fa8e10a978c5cfbf4b3156607459756ddaf633bb09693954fa1b56 url=/mulesoft/current/en-us/munit/2.3/test-recorder-examples.md -->

---
product: MUnit
version: 2.3
---

# Recording a Test from an Exchange Example

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

The following example shows you how to import to Anypoint Studio an existing project from Anypoint
Exchange and then record the flow processing to create a unit test for the flows.

## Prerequisite

- Your Anypoint Platform credentials are configured in Studio.  
  See [Configuring Anypoint Platform Credentials](https://docs.mulesoft.com/studio/set-credentials-in-studio-to) for
  more information.

## Test the Login Form Using the HTTP Connector Example

1.  Click the Open Exchange icon ![3%](/mulesoft/current/en-us/munit/2.3/_images/exchange-icon.png).

2.  Select **Provided by MuleSoft** in the pop-up Exchange window, filter per **Examples**, and look
    for the **Login Form Using the HTTP Connector**.

3.  Click **Open**.  
    Studio imports the example as a new working project.

4.  If prompted, select **Perform Update** in **Update your Workspace**.

5.  Select the Manage Mule Projects APIs icon ![2%](/mulesoft/current/en-us/munit/2.3/_images/manage-project-api-icon.png).

6.  Select **Modules** and update both **MUnit** and **Munit Tools**:

    ![update munit](/mulesoft/current/en-us/munit/2.3/_images/update-munit.png)

7.  Select **Apply and Close**.

### Test the Process for a Successful Login Attempt

1.  In your project, right-click `DoLoginFlow` and select **Munit** > **Record new test for this
    flow**:

    ![login flow test recorder example](/mulesoft/current/en-us/munit/2.3/_images/login-flow-test-recorder-example.png)

    The test recorder starts your project and starts recording the event going through that flow.

2.  Open a browser and navigate to `http://0.0.0.0:8081/login`.

3.  Type `mule` for both **Username** and **Password**, and click **Submit**.

    The test recorder captures this event and stops the recording.

4.  Return to Studio and click **Configure Test**:

    ![stops recording](/mulesoft/current/en-us/munit/2.3/_images/stops-recording.png)

5.  Select the file name for the MUnit test suite in which you want to record your test.

6.  Under **Test name**, type `_DoLoginFlow-successfull_`.

7.  Set the test recorder to set the recorded input of the flow, and assert that the recorded output
    is the expected output by the test.

8.  In **Successful login**, select **Verify that this process was called** and set the counter
    **equal to** to `_1_` time.

9.  Click **Next** and then **Finish**.

    A fully functional MUnit test is generated to assert that the process in your application works
    as expected when the login is successful.

### Test the Process for an Unsuccessful Login Attempt

1.  In your project, right-click `DoLoginFlow` and select **Munit** > **Record new test for this
    flow**:

    ![login flow test recorder example](/mulesoft/current/en-us/munit/2.3/_images/login-flow-test-recorder-example.png)

    The test recorder starts your project and starts recording the event going through that flow.

2.  Open a browser and navigate to `http://0.0.0.0:8081/login`.

3.  Type `admin` in both **Username** and **Password**, and click **Submit**:

    The test recorder captures this event and stops the recording.

4.  Return to Studio and click **Configure Test**:

    ![stops recording](/mulesoft/current/en-us/munit/2.3/_images/stops-recording.png)

5.  Select the file name for the MUnit test suite in which you want to record your test.

6.  Under **Test name**, type `_DoLoginFlow-unsuccessfull_`.

7.  Set the test recorder to set the recorded input of the flow, and assert that the recorded output
    is the expected output by the test.

8.  In the **Unsuccessful login** parse template step, select **Verify that this process was
    called** and set the counter to **equal to** `_1_` time.

9.  Click **Next** and then **Finish**.

    A fully functional MUnit test is generated to assert that the process in your application works
    as expected when the login fails.

## See Also

- [Test Recorder in Studio](https://docs.mulesoft.com/munit/2.3/test-recorder)

<!-- document id=ab9ed6db473e05e2e989901fc0dfac014cf20fd512cc0e2d4e9b5fd8408161f6 url=/mulesoft/current/en-us/munit/3.6/test-recorder-examples.md -->

---
product: MUnit
version: 3.6
---

# Recording a Test from an Exchange Example

> 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

The following example shows you how to import to Anypoint Studio an existing project from Anypoint
Exchange and then record the flow processing to create a unit test for the flows.

## Prerequisite

- Your Anypoint Platform credentials are configured in Studio.  
  See [Configuring Anypoint Platform Credentials](https://docs.mulesoft.com/studio/set-credentials-in-studio-to) for
  more information.

## Test the Login Form Using the HTTP Connector Example

1.  Click the Open Exchange icon ![3%](/mulesoft/current/en-us/munit/3.6/_images/exchange-icon.png).

2.  Select **Provided by MuleSoft** in the pop-up Exchange window, filter per **Examples**, and look
    for the **Login Form Using the HTTP Connector**.

3.  Click **Open**.  
    Studio imports the example as a new working project.

4.  If prompted, select **Perform Update** in **Update your Workspace**.

5.  Select the Manage Mule Projects APIs icon ![2%](/mulesoft/current/en-us/munit/3.6/_images/manage-project-api-icon.png).

6.  Select **Modules** and update both **MUnit** and **Munit Tools**:

    ![update munit](/mulesoft/current/en-us/munit/3.6/_images/update-munit.png)

7.  Select **Apply and Close**.

### Test the Process for a Successful Login Attempt

1.  In your project, right-click `DoLoginFlow` and select **Munit** > **Record new test for this
    flow**:

    ![login flow test recorder example](/mulesoft/current/en-us/munit/3.6/_images/login-flow-test-recorder-example.png)

    The test recorder starts your project and starts recording the event going through that flow.

2.  Open a browser and navigate to `http://0.0.0.0:8081/login`.

3.  Type `mule` for both **Username** and **Password**, and click **Submit**.

    The test recorder captures this event and stops the recording.

4.  Return to Studio and click **Configure Test**:

    ![stops recording](/mulesoft/current/en-us/munit/3.6/_images/stops-recording.png)

5.  Select the file name for the MUnit test suite in which you want to record your test.

6.  Under **Test name**, type `_DoLoginFlow-successfull_`.

7.  Set the test recorder to set the recorded input of the flow, and assert that the recorded output
    is the expected output by the test.

8.  In **Successful login**, select **Verify that this process was called** and set the counter
    **equal to** to `_1_` time.

9.  Click **Next** and then **Finish**.

    A fully functional MUnit test is generated to assert that the process in your application works
    as expected when the login is successful.

### Test the Process for an Unsuccessful Login Attempt

1.  In your project, right-click `DoLoginFlow` and select **Munit** > **Record new test for this
    flow**:

    ![login flow test recorder example](/mulesoft/current/en-us/munit/3.6/_images/login-flow-test-recorder-example.png)

    The test recorder starts your project and starts recording the event going through that flow.

2.  Open a browser and navigate to `http://0.0.0.0:8081/login`.

3.  Type `admin` in both **Username** and **Password**, and click **Submit**:

    The test recorder captures this event and stops the recording.

4.  Return to Studio and click **Configure Test**:

    ![stops recording](/mulesoft/current/en-us/munit/3.6/_images/stops-recording.png)

5.  Select the file name for the MUnit test suite in which you want to record your test.

6.  Under **Test name**, type `_DoLoginFlow-unsuccessfull_`.

7.  Set the test recorder to set the recorded input of the flow, and assert that the recorded output
    is the expected output by the test.

8.  In the **Unsuccessful login** parse template step, select **Verify that this process was
    called** and set the counter to **equal to** `_1_` time.

9.  Click **Next** and then **Finish**.

    A fully functional MUnit test is generated to assert that the process in your application works
    as expected when the login fails.

## See Also

- [Test Recorder in Studio](https://docs.mulesoft.com/munit/3.6/test-recorder)

<!-- document id=6cb44f58002935f6580c6df86fc95f15f86d113b10773040c051d8adaf424be7 url=/mulesoft/current/en-us/munit/2.3/resource-matchers-reference.md -->

---
product: MUnit
version: 2.3
---

# Resource Matchers

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

## getResourceAsStream(String)

Returns the resource from the path String as a stream.

Example

```xml
<set-payload
  value="#[MunitTools::getResourceAsStream('util/files/example.txt')]"/>
```

## getResourceAsReusableStream(String)

Returns the resource from the path String as a reusable stream.

Example

```xml
 <set-payload
   value="#[MunitTools::getResourceAsReusableStream('util/files/example.txt')]"/>
```

## getResourceAsString(path:String,encoding:String)

Returns the resource from the path String as a String, where the second parameter (encoding) is
optional.

Example

```xml
<set-payload
  value="#[MunitTools::getResourceAsString('util/files/example.txt')]"/>
```

You can also specify the encoding:

Example

```xml
<set-payload
  value="#[MunitTools::getResourceAsString('util/files/exampleISO.txt', 'ISO-8859-1')]"/>
```

## getResourceAsByteArray(String)

Returns the resource from the path String as a byte array.

Example

```xml
 <set-payload
   value="#[MunitTools::getResourceAsByteArray('util/files/example.txt')]"/>
```

## queueSize(String)

Returns the size of the queue specified inside `#[MunitTools::queueSize()]`.

For example, to assert the size of a queue named `QUEUE_SIZE`:

Example

```xml
<munit:execution>
  <munit-tools:queue queueName="QUEUE_SIZE">
    <munit-tools:value>#['EXAMPLE']</munit-tools:value>
  </munit-tools:queue>
</munit:execution>

<munit:validation>
  <munit-tools:assert-that expression="#[MunitTools::queueSize('QUEUE_SIZE')]" is="#[MunitTools::equalTo(1)]"/>
</munit:validation>
```

## createMessage(payload: Any, mimeType: String|Null , attributes: Any, attributeMimeType: String|Null)

Creates a Mule message with the specified attributes.

Example

```xml
<munit:execution>
     <set-payload value="#[MunitTools::createMessage( 'ITEM-1',  'text/plain', { property : 'ATTRIBUTE-1'}, null )]"/>
 </munit:execution>
```

## See Also

- [MUnit Matchers](https://docs.mulesoft.com/munit/2.3/munit-matchers)

- [Core Matchers Reference](https://docs.mulesoft.com/munit/2.3/core-matchers-reference)

- [String Matchers Reference](https://docs.mulesoft.com/munit/2.3/string-matchers-reference)

- [Comparable Matchers Reference](https://docs.mulesoft.com/munit/2.3/comparable-matchers-reference)

<!-- document id=88a520607b687578c6d5d16f5a541381cff8ceaa5e68ee80f7e37fa84dfe23c1 url=/mulesoft/current/en-us/munit/3.6/resource-matchers-reference.md -->

---
product: MUnit
version: 3.6
---

# Resource Matchers

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

## getResourceAsStream(String)

Returns the resource from the path String as a stream.

Example

```xml
<set-payload
  value="#[MunitTools::getResourceAsStream('util/files/example.txt')]"/>
```

## getResourceAsReusableStream(String)

Returns the resource from the path String as a reusable stream.

Example

```xml
 <set-payload
   value="#[MunitTools::getResourceAsReusableStream('util/files/example.txt')]"/>
```

## getResourceAsString(path:String,encoding:String)

Returns the resource from the path String as a String, where the second parameter (encoding) is
optional.

Example

```xml
<set-payload
  value="#[MunitTools::getResourceAsString('util/files/example.txt')]"/>
```

You can also specify the encoding:

Example

```xml
<set-payload
  value="#[MunitTools::getResourceAsString('util/files/exampleISO.txt', 'ISO-8859-1')]"/>
```

## getResourceAsByteArray(String)

Returns the resource from the path String as a byte array.

Example

```xml
 <set-payload
   value="#[MunitTools::getResourceAsByteArray('util/files/example.txt')]"/>
```

## queueSize(String)

Returns the size of the queue specified inside `#[MunitTools::queueSize()]`.

For example, to assert the size of a queue named `QUEUE_SIZE`:

Example

```xml
<munit:execution>
  <munit-tools:queue queueName="QUEUE_SIZE">
    <munit-tools:value>#['EXAMPLE']</munit-tools:value>
  </munit-tools:queue>
</munit:execution>

<munit:validation>
  <munit-tools:assert-that expression="#[MunitTools::queueSize('QUEUE_SIZE')]" is="#[MunitTools::equalTo(1)]"/>
</munit:validation>
```

## createMessage(payload: Any, mimeType: String|Null , attributes: Any, attributeMimeType: String|Null)

Creates a Mule message with the specified attributes.

Example

```xml
<munit:execution>
     <set-payload value="#[MunitTools::createMessage( 'ITEM-1',  'text/plain', { property : 'ATTRIBUTE-1'}, null )]"/>
 </munit:execution>
```

## See Also

- [MUnit Matchers](https://docs.mulesoft.com/munit/3.6/munit-matchers)

- [Core Matchers Reference](https://docs.mulesoft.com/munit/3.6/core-matchers-reference)

- [String Matchers Reference](https://docs.mulesoft.com/munit/3.6/string-matchers-reference)

- [Comparable Matchers Reference](https://docs.mulesoft.com/munit/3.6/comparable-matchers-reference)

<!-- document id=788915b6c51272097ce6c2a583683f2cf7454bf4453c8311528aaf0d3eb75f10 url=/mulesoft/current/en-us/munit/2.3/run-custom-event-processor.md -->

---
product: MUnit
version: 2.3
keywords: mule, esb, tests, qa, quality assurance, verify, functional testing, unit testing, stress testing
---

# Run Custom Event Processor

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

The **Run Custom event processor** enables you to assert the Mule event content against a custom
assertion.

To add the **Run Custom processor** to your project, add the following dependency to your `pom.xml`
file:

```xml
<dependency>
    <groupId>com.mulesoft.munit</groupId>
    <artifactId>munit-assert</artifactId>
    <version>${munit.version}</version>
    <scope>test</scope>
</dependency>
```

You also have to add your custom assertion class to the `mule-artifact.json` file as an exported
resource.

For example, you can define the following assertion in Java:

```java
package org.mule.custom;
import org.mule.munit.assertion.api.MunitAssertion;
import org.mule.munit.assertion.api.TypedValue;

public class CustomAssertion implements MunitAssertion {

    @Override
    public void execute(TypedValue expression, Object params) throws AssertionError { (1)
        if (!"Hello World".equals(expression.getValue())) { (2)
            throw new AssertionError("Error the payload is incorrect");
        }
     }

}
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Implement the only method in the interface <code>public void execute(TypedValue expression, Object params) throws AssertionError</code>.</td></tr><tr><td><i data-value="2"></i><b>2</b></td><td>Run your custom logic, which in this case validates that the message payload is <code>Hello World</code>.</td></tr></tbody></table>

The `CustomAssertion` class must be located in the scr/test/java directory.

And use the **Run Custom Event Processor** to run it:

```xml
<munit-tools:run-custom
  assertion="org.mule.custom.CustomAssertion" (1)
  expression="#[payload]"/>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>The assertion field needs to have the canonical class name of your custom assertion and the class needs to be exported.</td></tr></tbody></table>

To export it when packaging your application, add the `org.mule.custom` package to your
`mule-artifact.json`

```json
{
  "name": "mule-application",
  "minMuleVersion": "4.2.0",
  "classLoaderModelLoaderDescriptor": {
    "id": "mule",
    "attributes": {
      "exportedPackages": ["org.mule.custom"]
    }
  }
}
```

> [!NOTE] You only need to configure the package name in the `exportedPackages` collection.

## See Also

- [MUnit Matchers](https://docs.mulesoft.com/munit/2.3/munit-matchers)

- [Assert That Event Processor](https://docs.mulesoft.com/munit/2.3/assertion-event-processor)

- [Set Event Processor](https://docs.mulesoft.com/munit/2.3/set-event-processor)

- [Mock When Event Processor](https://docs.mulesoft.com/munit/2.3/mock-event-processor)

- [Verify Event Processor](https://docs.mulesoft.com/munit/2.3/verify-event-processor)

- [Fail Event Processor](https://docs.mulesoft.com/munit/2.3/fail-event-processor)

<!-- document id=96f7d4b69373a71dae296e190212b022dded637325837e0b8858ec1ecf02c691 url=/mulesoft/current/en-us/munit/3.6/run-custom-event-processor.md -->

---
product: MUnit
version: 3.6
keywords: mule, esb, tests, qa, quality assurance, verify, functional testing, unit testing, stress testing
---

# Run Custom Event Processor

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The **Run Custom event processor** enables you to assert the Mule event content against a custom
assertion.

To add the **Run Custom processor** to your project, add the following dependency to your `pom.xml`
file:

```xml
<dependency>
    <groupId>com.mulesoft.munit</groupId>
    <artifactId>munit-assert</artifactId>
    <version>${munit.version}</version>
    <scope>test</scope>
</dependency>
```

You also have to add your custom assertion class to the `mule-artifact.json` file as an exported
resource.

For example, you can define the following assertion in Java:

```java
package org.mule.custom;
import org.mule.munit.assertion.api.MunitAssertion;
import org.mule.munit.assertion.api.TypedValue;

public class CustomAssertion implements MunitAssertion {

    @Override
    public void execute(TypedValue expression, Object params) throws AssertionError { (1)
        if (!"Hello World".equals(expression.getValue())) { (2)
            throw new AssertionError("Error the payload is incorrect");
        }
     }

}
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Implement the only method in the interface <code>public void execute(TypedValue expression, Object params) throws AssertionError</code>.</td></tr><tr><td><i data-value="2"></i><b>2</b></td><td>Run your custom logic, which in this case validates that the message payload is <code>Hello World</code>.</td></tr></tbody></table>

The `CustomAssertion` class must be located in the scr/test/java directory.

And use the **Run Custom Event Processor** to run it:

```xml
<munit-tools:run-custom
  assertion="org.mule.custom.CustomAssertion" (1)
  expression="#[payload]"/>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>The assertion field needs to have the canonical class name of your custom assertion and the class needs to be exported.</td></tr></tbody></table>

To export it when packaging your application, add the `org.mule.custom` package to your
`mule-artifact.json`

```json
{
  "name": "mule-application",
  "minMuleVersion": "4.2.0",
  "classLoaderModelLoaderDescriptor": {
    "id": "mule",
    "attributes": {
      "exportedPackages": ["org.mule.custom"]
    }
  }
}
```

> [!NOTE] You only need to configure the package name in the `exportedPackages` collection.

## See Also

- [MUnit Matchers](https://docs.mulesoft.com/munit/3.6/munit-matchers)

- [Assert That Event Processor](https://docs.mulesoft.com/munit/3.6/assertion-event-processor)

- [Set Event Processor](https://docs.mulesoft.com/munit/3.6/set-event-processor)

- [Mock When Event Processor](https://docs.mulesoft.com/munit/3.6/mock-event-processor)

- [Verify Event Processor](https://docs.mulesoft.com/munit/3.6/verify-event-processor)

- [Fail Event Processor](https://docs.mulesoft.com/munit/3.6/fail-event-processor)

<!-- document id=de465e17132b4b4e672de0c28b9cfda3b53eb042f26ca146f86074307a2cf4dd url=/mulesoft/current/en-us/munit/latest/coverage-studio-concept.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# Run MUnit Coverage Reports in Anypoint Studio

> 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

Run MUnit coverage reports in Anypoint Studio to see which flows and event processors your tests
cover. These configurations apply only when running MUnit tests in Studio, not from Maven in a CI/CD
environment.

## Enable Coverage Reports in Anypoint Studio

You can see which flows, and which percentage of event processors in those flows the test covers by
clicking on the Coverage button:

![MUnit Coverage tab highlighted in the MUnit section](/mulesoft/current/en-us/munit/latest/_images/using-munit-coverage-in-anypoint-studio.png)

The Overall Coverage value represents the percentage of the Mule application event processors that
the MUnit test executes.

You can click **Generate Report** to get the report that details the flows and event processors in
the Mule configuration files that are included in the MUnit test.

![Files included in the report highlighted](/mulesoft/current/en-us/munit/latest/_images/munit-coverage-report-in-anypoint-studio.png)

<table><colgroup><col> <col></colgroup><thead><tr><th>Column</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><strong>Resource</strong></p></div></div></td><td><div><div><p>Name of the Mule configuration file</p></div></div></td></tr><tr><td><div><div><p><strong>Containers</strong></p></div></div></td><td><div><div><p>Number of flows inside the Mule configuration file</p></div></div></td></tr><tr><td><div><div><p><strong>Weight</strong></p></div></div></td><td><div><div><p>Percentage of your application in a configuration file<br>A percentage of the overall number of event processors in the documentation and the number of event processors in the Mule configuration file</p></div></div></td></tr><tr><td><div><div><p><strong>Coverage</strong></p></div></div></td><td><div><div><p>Percentage of event processors in the Mule configuration file that the MUnit test executes</p></div></div></td></tr></tbody></table>

Additionally, you can click on each **Resource** to get a more specific and granular report of the
Event Processors executed in that resource:

![MUnit Coverage Report with the Granular report highlighted](/mulesoft/current/en-us/munit/latest/_images/munit-granular-coverage-report-in-anypoint-studio.png)

<table><colgroup><col> <col></colgroup><thead><tr><th>Column</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><strong>Name</strong></p></div></div></td><td><div><div><p>Name of the container</p></div></div></td></tr><tr><td><div><div><p><strong>Type</strong></p></div></div></td><td><div><div><p>Type of the container</p></div></div></td></tr><tr><td><div><div><p><strong>Covered Processors</strong></p></div></div></td><td><div><div><p>Processors inside the container that are executed during the MUnit test</p></div></div></td></tr><tr><td><div><div><p><strong>Processors</strong></p></div></div></td><td><div><div><p>Total amount of processors inside the container</p></div></div></td></tr><tr><td><div><div><p><strong>Coverage</strong></p></div></div></td><td><div><div><p>Percentage of the event processors inside the container executed in the MUnit test</p></div></div></td></tr></tbody></table>

## Disable Coverage Reports

If you choose so, you can disable the coverage calculation from your project run configuration so
you test your flow without a coverage report.

Right-click **Package Explorer** and choose **Run As** > **Run Configurations**. Select your MUnit
run configuration file to access your suite configuration, and deselect the **Run coverage** option
in your coverage settings.

![MUnit run and Run coverage highlighted](/mulesoft/current/en-us/munit/latest/_images/disable-munit-coverage-in-anypoint-studio.png)

## Exclude XML Files from MUnit Coverage Report

You can exclude one or more XML files from an MUnit Coverage report when testing your application.
For example, you can exclude a third-party XML file that does not comply with your quality standards
to improve your final report score.

1.  Go to the flow to change.

2.  Click **Run** > **Run Configuration**.

3.  Click the name of your project.

4.  In the **Ignored files** section, click **Add**.

    ![Add Ignored File window highlighted in the Test tab](/mulesoft/current/en-us/munit/latest/_images/add-ignored-files.png)

5.  Type the name of the XML file to exclude from the Coverage report and click **OK**.

6.  Click **Apply** and **Run**.

## See Also

- [MUnit Coverage Report](https://docs.mulesoft.com/munit/latest/munit-coverage-report)

- [Configure MUnit Coverage in Maven](https://docs.mulesoft.com/munit/latest/coverage-maven-concept)

<!-- document id=9b99ce48a98212d75e9610ab104752572b976016597c21b55bd1c9f3a4fef890 url=/mulesoft/current/en-us/munit/2.3/munit-scaffold-test-task.md -->

---
product: MUnit
version: 2.3
---

# Scaffold a Template for an MUnit Test from an API Specification

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

You can use APIKit to automatically generate an empty structure for an MUnit test suite based on
your API specification.

Because your Mule project is generated using APIKit, you can use APIKit to automatically scaffold an
empty MUnit test suite, based on the endpoints described in your API specification. Scaffolding does
not generate the test itself, but generates a tool to help you start writing the test.

To create this empty test suite:

1.  Locate and right-click the APIKit router in your project.

2.  Select **Create Test Suite for Project From API Specification**.

<!-- document id=4281ac8853745f525c633b347c649e8d042622714c612d58ec1c11821e24586a url=/mulesoft/current/en-us/munit/3.6/munit-scaffold-test-task.md -->

---
product: MUnit
version: 3.6
---

# Scaffold a Template for an MUnit Test from an API Specification

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

You can use APIkit to automatically generate an empty structure for an MUnit test suite based on
your API specification.

Because your Mule project is generated using APIkit, you can use APIkit to automatically scaffold an
empty MUnit test suite, based on the endpoints described in your API specification. Scaffolding does
not generate the test itself, but generates a tool to help you start writing the test.

To create this empty test suite:

1.  Locate and right-click the APIkit router in your project.

2.  Select **Create Test Suite for Project From API Specification**.

<!-- document id=be3092414215e074ca4a342878623ea9c4e4335ec88348740bb2e21f77ac1222 url=/mulesoft/current/en-us/munit/latest/munit-scaffold-test-task.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# Scaffold an MUnit Test Suite from an API Specification

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

Use APIkit to scaffold an empty MUnit test suite structure based on the endpoints defined in your
API specification. Scaffolding generates the test suite file but not the individual tests, giving
you a starting point for writing your MUnit tests.

To create this empty test suite:

1.  Locate and right-click the APIkit router in your project.

2.  Select **Create Test Suite for Project From API Specification**.

<!-- document id=d8931027170e2d5f31ef7e32d38980fa4c2c080f4d432ab3eff89b098345e340 url=/mulesoft/current/en-us/munit/2.3/set-event-processor.md -->

---
product: MUnit
version: 2.3
keywords: munit, testing, unit testing
---

# Set Event Processor

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

The Set Event Processor allows you to define a Mule Event.  
This message processor is normally used at the beginning of an MUnit test, to define the first
message to send to the flow being tested.

The example below shows how to define a simple payload of a Mule Message:

```xml
<munit:set-event cloneOriginalEvent="false">
  <munit:payload value="#['payload_value']" mediaType="text/plain" encoding="UTF-8"/>
</munit:set-event>
```

The set-event has the cloneOriginalEvent property. If set to true, it clones the event produced by
your code.  
By default, the value of this property is false.

The payload element in the Set Event processor has the following attributes:

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>value</code></p></td><td><p>Defines the value of the payload’s message.</p></td></tr><tr><td><p><code>encoding</code></p></td><td><p>Defines the encoding of the message. This attribute is optional.</p></td></tr><tr><td><p><code>mediaType</code></p></td><td><p>Defines the mime type of the message. This attribute is optional.</p></td></tr></tbody></table>

You can also use the Set Event processor to define message attributes and event variables:

```xml
<munit:set-event cloneOriginalEvent="false">
  <munit:payload value="#['Example Body']" mediaType="text/plain" encoding="UTF-8"/>

  <munit:attributes value="#[{ method : 'GET', queryParams : { page : '1'}}]" />

  <munit:variables>
    <munit:variable key="variable_key" value="#['example']" mediaType="text/plain" encoding="UTF-8"/>
  </munit:variables>
</munit:set-event>
```

All the properties have the same set of attributes:

<table><caption>Table 1. Property Message Processor’s Attributes</caption> <colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>key</code></p></td><td><p>The key of the property being set.</p></td></tr><tr><td><p><code>value</code></p></td><td><p>The content of the property.</p></td></tr><tr><td><p><code>encoding</code></p></td><td><p>Defines the encoding of the message. This attribute is optional.</p></td></tr><tr><td><p><code>mediaType</code></p></td><td><p>Defines the mime type of the message. This attribute is optional.</p></td></tr></tbody></table>

You can define as many properties per each scope as you need for your test.

> [!WARNING] If you define two properties in the same scope with the _same_ key, be aware that one
> would end up overwriting the other.

## See Also

- [Testing and Mocking Errors](https://docs.mulesoft.com/munit/2.3/test-mock-errors-cookbook)

- [Fail Event Processor](https://docs.mulesoft.com/munit/2.3/fail-event-processor)

- [Run Custom Event Processor](https://docs.mulesoft.com/munit/2.3/run-custom-event-processor)

<!-- document id=8c1c666e6dbd837543b50dafe4c2bd1fe67bdd8e61ae697032392b16552d5eea url=/mulesoft/current/en-us/munit/3.6/set-event-processor.md -->

---
product: MUnit
version: 3.6
keywords: munit, testing, unit testing
---

# Set Event Processor

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The Set Event Processor allows you to define a Mule Event.  
This message processor is normally used at the beginning of an MUnit test, to define the first
message to send to the flow being tested.

The example below shows how to define a simple payload of a Mule Message:

```xml
<munit:set-event cloneOriginalEvent="false">
  <munit:payload value="#['payload_value']" mediaType="text/plain" encoding="UTF-8"/>
</munit:set-event>
```

The set-event has the cloneOriginalEvent property. If set to true, it clones the event produced by
your code.  
By default, the value of this property is false.

The payload element in the Set Event processor has the following attributes:

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>value</code></p></td><td><p>Defines the value of the payload’s message.</p></td></tr><tr><td><p><code>encoding</code></p></td><td><p>Defines the encoding of the message. This attribute is optional.</p></td></tr><tr><td><p><code>mediaType</code></p></td><td><p>Defines the mime type of the message. This attribute is optional.</p></td></tr></tbody></table>

You can also use the Set Event processor to define message attributes and event variables:

```xml
<munit:set-event cloneOriginalEvent="false">
  <munit:payload value="#['Example Body']" mediaType="text/plain" encoding="UTF-8"/>

  <munit:attributes value="#[{ method : 'GET', queryParams : { page : '1'}}]" />

  <munit:variables>
    <munit:variable key="variable_key" value="#['example']" mediaType="text/plain" encoding="UTF-8"/>
  </munit:variables>
</munit:set-event>
```

All the properties have the same set of attributes:

<table><caption>Table 1. Property Message Processor’s Attributes</caption> <colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>key</code></p></td><td><p>The key of the property being set.</p></td></tr><tr><td><p><code>value</code></p></td><td><p>The content of the property.</p></td></tr><tr><td><p><code>encoding</code></p></td><td><p>Defines the encoding of the message. This attribute is optional.</p></td></tr><tr><td><p><code>mediaType</code></p></td><td><p>Defines the mime type of the message. This attribute is optional.</p></td></tr></tbody></table>

You can define as many properties per each scope as you need for your test.

> [!WARNING] If you define two properties in the same scope with the _same_ key, be aware that one
> would end up overwriting the other.

## See Also

- [Testing and Mocking Errors](https://docs.mulesoft.com/munit/3.6/test-mock-errors-cookbook)

- [Fail Event Processor](https://docs.mulesoft.com/munit/3.6/fail-event-processor)

- [Run Custom Event Processor](https://docs.mulesoft.com/munit/3.6/run-custom-event-processor)

<!-- document id=1c84dbba92ac7f6eab16e20f909691730c95bd1f8137991762a2fb8a0076ef1a url=/mulesoft/current/en-us/munit/2.3/sleep-processor.md -->

---
product: MUnit
version: 2.3
---

# Sleep Processor

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

The Sleep processor allows you to pause your test for a specific time. You can use this processor to
simulate a delay in the processing of the flow:

```xml
<munit-tools:sleep time="100" timeUnit="MILLISECONDS"/>
```

`time`

Numerical value for the unit of time that your test waits before going to sleep.

`timeUnit`

The unit in which the `time` value is measured.

Possible values are:

- `MILLISECONDS` (default)

- `MICROSECONDS`

- `MINUTES`

- `NANOSECONDS`

- `SECONDS`

- `HOURS`

<!-- document id=e36f367309df1751c0b9fbd34b70ad5e60beb52386ae92f69adb894c2c0dc354 url=/mulesoft/current/en-us/munit/3.6/sleep-processor.md -->

---
product: MUnit
version: 3.6
---

# Sleep Processor

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The Sleep processor allows you to pause your test for a specific time. You can use this processor to
simulate a delay in the processing of the flow:

```xml
<munit-tools:sleep time="100" timeUnit="MILLISECONDS"/>
```

`time`

Numerical value for the unit of time that your test waits before going to sleep.

`timeUnit`

The unit in which the `time` value is measured.

Possible values are:

- `MILLISECONDS` (default)

- `MICROSECONDS`

- `MINUTES`

- `NANOSECONDS`

- `SECONDS`

- `HOURS`

<!-- document id=c624e9f1dc389b23aff368a31be415fb555b2a0436a11d50fefb23f3533596dd url=/mulesoft/current/en-us/munit/2.3/spy-event-processor.md -->

---
product: MUnit
version: 2.3
keywords: munit, testing, unit testing
---

# Spy Event Processor

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

The **Spy Processor** enables you to spy on what happens before and after an event processor is
called.  
This enables you to validate, for example that a selected Mule Event reaches a specific event
processor containing a specific payload or variable.

Setting a spy processor tells MUnit to run a set of instructions (usually assertions or
verifications) before and/or after the execution of the spied event processor.

Assume that you have this configuration:

```xml
<flow name="testFlow">
  <http:request path="/my/api" />
</flow>
```

You can configure the spy processor to spy on any Http Request and assert that the payload is null
before reaching the component, and not null after it’s been processed:

```xml
<munit:test name="suiteTest" >

  <munit:behavior >

    <munit-tools:spy processor="http:request">
      <munit-tools:before-call >
        <munit-tools:assert-that expression="#[payload]" is="#[MunitTools::nullValue()]"/>
      </munit-tools:before-call>
      <munit-tools:after-call >
        <munit-tools:assert-that expression="#[payload]" is="#[MunitTools::notNullValue()]"/>
      </munit-tools:after-call>
    </munit-tools:spy>

  </munit:behavior>

</munit:test>
```

Or even to spy on any Http Request, whose path is '/my/api'.

```xml
<munit:test name="suiteTest" >

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

  <munit:behavior >

    <munit-tools:spy processor="http:request">
      <munit-tools:with-attributes >
        <munit-tools:with-attribute attributeName="path" whereValue="#['/my/api']" />
      </munit-tools:with-attributes>

      <munit-tools:before-call >
        <munit-tools:assert-that expression="#[payload]" is="#[MunitTools::nullValue()]"/>
      </munit-tools:before-call>

      <munit-tools:after-call >
        <munit-tools:assert-that expression="#[payload]" is="#[MunitTools::notNullValue()]"/>
      </munit-tools:after-call>

    </munit-tools:spy>

  </munit:behavior>

</munit:test>
```

As shown above, this processor enables you to define actions for before and after calling the spied
processor. However, keep in mind that the spy processor does not modify the original Mule Event.  
If you set variables, attributes, or modify the payload inside a Spy, these changes won’t persist
outside the processor.  
Overall, you should use the Spy processor to verify or assert.

## See Also

- [MUnit Event Processors](https://docs.mulesoft.com/munit/2.3/event-processors)

<!-- document id=545b43432b43ebe615f7d4301fb4f18a1a9c8cd36b57008fac66629de8d38aa6 url=/mulesoft/current/en-us/munit/3.6/spy-event-processor.md -->

---
product: MUnit
version: 3.6
keywords: munit, testing, unit testing
---

# Spy Event Processor

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The **Spy Processor** enables you to spy on what happens before and after an event processor is
called.  
This enables you to validate, for example that a selected Mule Event reaches a specific event
processor containing a specific payload or variable.

Setting a spy processor tells MUnit to run a set of instructions (usually assertions or
verifications) before and/or after the execution of the spied event processor.

Assume that you have this configuration:

```xml
<flow name="testFlow">
  <http:request path="/my/api" />
</flow>
```

You can configure the spy processor to spy on any Http Request and assert that the payload is null
before reaching the component, and not null after it’s been processed:

```xml
<munit:test name="suiteTest" >

  <munit:behavior >

    <munit-tools:spy processor="http:request">
      <munit-tools:before-call >
        <munit-tools:assert-that expression="#[payload]" is="#[MunitTools::nullValue()]"/>
      </munit-tools:before-call>
      <munit-tools:after-call >
        <munit-tools:assert-that expression="#[payload]" is="#[MunitTools::notNullValue()]"/>
      </munit-tools:after-call>
    </munit-tools:spy>

  </munit:behavior>

</munit:test>
```

Or even to spy on any Http Request, whose path is '/my/api'.

```xml
<munit:test name="suiteTest" >

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

  <munit:behavior >

    <munit-tools:spy processor="http:request">
      <munit-tools:with-attributes >
        <munit-tools:with-attribute attributeName="path" whereValue="#['/my/api']" />
      </munit-tools:with-attributes>

      <munit-tools:before-call >
        <munit-tools:assert-that expression="#[payload]" is="#[MunitTools::nullValue()]"/>
      </munit-tools:before-call>

      <munit-tools:after-call >
        <munit-tools:assert-that expression="#[payload]" is="#[MunitTools::notNullValue()]"/>
      </munit-tools:after-call>

    </munit-tools:spy>

  </munit:behavior>

</munit:test>
```

As shown above, this processor enables you to define actions for before and after calling the spied
processor. However, keep in mind that the spy processor does not modify the original Mule Event.  
If you set variables, attributes, or modify the payload inside a Spy, these changes won’t persist
outside the processor.  
Overall, you should use the Spy processor to verify or assert.

## See Also

- [MUnit Event Processors](https://docs.mulesoft.com/munit/3.6/event-processors)

<!-- document id=facf33f3c26f1ebabe69b8d11155a2176fe9564ba4e8db1238b0594389922916 url=/mulesoft/current/en-us/munit/2.3/storage-event-processors.md -->

---
product: MUnit
version: 2.3
---

# Storage Event Processors

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

The Storage processors allows you to manage temporary storage during your tests.

All storage is cleared as soon as the test ends.

## Store operation

Stores the given data associated with the given key. If `value` not set, it defaults to the
`payload`.

```xml
<munit-tools:store key="myKey">
    <munit-tools:value>#[person : { name: 'John', lastName: 'Smith' }]</munit-tools:value>
</munit-tools:store>
```

## Retrieve operation

Retrieves the data associated with the given key

```xml
<munit-tools:retrieve key="myKey"/>
```

## Remove operation

Removes and returns the data associated with the given key

```xml
<munit-tools:remove key="myKey"/>
```

## Clear stored data operation

Clears all stored data

```xml
<munit-tools:clear-stored-data/>
```

<!-- document id=0c5dea8aadbdddb5e647ed75b12f76ab41ede813e403d129842c2e6695e0afc9 url=/mulesoft/current/en-us/munit/3.6/storage-event-processors.md -->

---
product: MUnit
version: 3.6
---

# Storage Event Processors

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The Storage processors allows you to manage temporary storage during your tests.

All storage is cleared as soon as the test ends.

## Store operation

Stores the given data associated with the given key. If `value` not set, it defaults to the
`payload`.

```xml
<munit-tools:store key="myKey">
    <munit-tools:value>#[person : { name: 'John', lastName: 'Smith' }]</munit-tools:value>
</munit-tools:store>
```

## Retrieve operation

Retrieves the data associated with the given key

```xml
<munit-tools:retrieve key="myKey"/>
```

## Remove operation

Removes and returns the data associated with the given key

```xml
<munit-tools:remove key="myKey"/>
```

## Clear stored data operation

Clears all stored data

```xml
<munit-tools:clear-stored-data/>
```

<!-- document id=dc38472c91cbd015477dc57c7cd0293954bef36298a28cfa2f221bb95663c852 url=/mulesoft/current/en-us/munit/2.3/string-matchers-reference.md -->

---
product: MUnit
version: 2.3
---

# String Matchers Reference

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

## containsString(String)

Checks that the expression contains the specified String.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::containsString('example')]"/>
```

## startsWith(String)

Checks that the expression starts with the specified String.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::startsWith('exam')]"/>
```

## endsWith(String)

Checks that the expression ends with the specified String.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::endsWith('ple')]"/>
```

## isEmptyString()

Checks that the expression has zero length.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::isEmptyString()]"/>
```

## isEmptyOrNullString()

Checks that the expression is null, or has zero length.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::isEmptyOrNullString()]"/>
```

## equalToIgnoringCase(String)

Checks that the expression is equal to the specified String, ignoring case.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::equalToIgnoringCase('example')]"/>
```

## equalToIgnoringWhiteSpace(String)

Checks that the expression is equal to the string disregarding leading and trailing white spaces,
and compression all inner white spaces to a single space.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::equalToIgnoringWhiteSpace('An Example')]"/>
```

## stringContainsInOrder(Array<String>)

Checks that the expression contains all of the specified substrings, regardless of the order of
their appearance.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::stringContainsInOrder(['an', 'example'])]"/>
```

## See Also

- [MUnit Matchers](https://docs.mulesoft.com/munit/2.3/munit-matchers)

- [Core Matchers Reference](https://docs.mulesoft.com/munit/2.3/core-matchers-reference)

- [Comparable Matchers Reference](https://docs.mulesoft.com/munit/2.3/comparable-matchers-reference)

- [Iterable and Map Matchers Reference](https://docs.mulesoft.com/munit/2.3/iterable-map-matchers-reference)

<!-- document id=d66d91d3ecbf876c5be1e2726c28fffe2e62932136af95f89896c94e602b21ef url=/mulesoft/current/en-us/munit/3.6/string-matchers-reference.md -->

---
product: MUnit
version: 3.6
---

# String Matchers Reference

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

## containsString(String)

Checks that the expression contains the specified String.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::containsString('example')]"/>
```

## startsWith(String)

Checks that the expression starts with the specified String.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::startsWith('exam')]"/>
```

## endsWith(String)

Checks that the expression ends with the specified String.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::endsWith('ple')]"/>
```

## isEmptyString()

Checks that the expression has zero length.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::isEmptyString()]"/>
```

## isEmptyOrNullString()

Checks that the expression is null, or has zero length.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::isEmptyOrNullString()]"/>
```

## equalToIgnoringCase(String)

Checks that the expression is equal to the specified String, ignoring case.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::equalToIgnoringCase('example')]"/>
```

## equalToIgnoringWhiteSpace(String)

Checks that the expression is equal to the string disregarding leading and trailing white spaces,
and compression all inner white spaces to a single space.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::equalToIgnoringWhiteSpace('An Example')]"/>
```

## stringContainsInOrder(Array<String>)

Checks that the expression contains all of the specified substrings, regardless of the order of
their appearance.

Example

```xml
<munit-tools:assert-that
expression="#[payload]"
is="#[MunitTools::stringContainsInOrder(['an', 'example'])]"/>
```

## See Also

- [MUnit Matchers](https://docs.mulesoft.com/munit/3.6/munit-matchers)

- [Core Matchers Reference](https://docs.mulesoft.com/munit/3.6/core-matchers-reference)

- [Comparable Matchers Reference](https://docs.mulesoft.com/munit/3.6/comparable-matchers-reference)

- [Iterable and Map Matchers Reference](https://docs.mulesoft.com/munit/3.6/iterable-map-matchers-reference)

<!-- document id=6869d3bf2a5a5a021644640f7e750f3ea7921e085e67159b96de1854eff6af9e url=/mulesoft/current/en-us/munit/latest/test-flow-with-scheduler-cookbook.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# Test a Flow with a Scheduler Source in MUnit

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

Test a Mule flow triggered by a Scheduler component in MUnit by enabling flow sources and using the
verify-call processor to confirm the flow executes. Wrap verify-call inside an until-successful
scope to handle timing variations in the Scheduler.

Assume that you want to both test the following flow triggered by a Scheduler component and validate
that your flow is being triggered correctly:

```xml
<flow name="schedulerFlow">
    <scheduler>
        <scheduling-strategy >
            <fixed-frequency frequency="10" timeUnit="SECONDS"/>
        </scheduling-strategy>
    </scheduler>
    <set-payload value="#['test poll']"/>
</flow>
```

1.  Enable flow sources.  
    Because MUnit does not start any of the flow sources (such as triggers or listeners), you must
    configure which flow sources start for your tests.

    In this example, you enable the flow that contains the Scheduler:

    ```xml
    <munit:test name="test-schedulerFlowTest">
        <munit:enable-flow-sources>
            <munit:enable-flow-source value="schedulerFlow"/>
        </munit:enable-flow-sources>
    </munit:test>
    ```

2.  Verify that flow execution is triggered by the Scheduler.  
    To verify that the processors inside your flow are being triggered, use the
    `munit-tools:verify-call` processor.

    Wrap `munit-tools:verify-call` inside an `until-successful` to shorten processing time when the
    Scheduler is not operating when you want to test.

    The following example validates three times that the payload was executed at least once during
    the test.

    ```xml
    <munit:execution>
        <until-successful maxRetries="3" millisBetweenRetries="100">
            <munit-tools:verify-call processor="set-payload" atLeast="1">
                <munit-tools:with-attributes >
                    <munit-tools:with-attribute whereValue="#['test poll']" attributeName="value" />
                </munit-tools:with-attributes>
            </munit-tools:verify-call>
        </until-successful>
    </munit:execution>
    ```

## See Also

- [Enable Flow Sources](https://docs.mulesoft.com/munit/latest/enable-flow-sources-concept)

- [Verify Event Processor](https://docs.mulesoft.com/munit/latest/verify-event-processor)

<!-- document id=496629c39e4411e92114b258bff8b4762d0b23e79fb6b575b3acbc43085b8e7b url=/mulesoft/current/en-us/munit/latest/test-mock-errors-cookbook.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# Test and Mock Errors in MUnit

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

Test and mock error handling in MUnit by configuring expected error types, using mock-when to
simulate errors, or setting errors directly on the Mule event. Use these techniques to validate
on-error-continue and on-error-propagate scopes in your flows.

## Expect an Error in Your Test

During the execution of a flow, components may throw errors which might be expected for the use case
being tested. In these cases, you want to specify that your test expects a particular error type or
exception.

For example, lets look at the following Mule code:

```xml
<flow name="retrieveKey">
    <os:retrieve key="#[payload.key]"/>
    <set-variable value="#[payload.id]" variableName="userId"/>
</flow>
```

The key is taken from the payload and if the key is `null`, the Object Store connector will throw an
error with `OS:INVALID_KEY` error type.

The test to validate this case would be something like this:

```xml
<munit:test name="retrieveNullKeyTest" description="Expect error when key is null" expectedErrorType="OS:INVALID_KEY">
    <munit:behavior>
        <munit:set-event>
            <munit:payload value="#[ { key: null}]" />
        </munit:set-event>
    </munit:behavior>
    <munit:execution>
        <flow-ref name="retrieveKey"/>
    </munit:execution>
</munit:test>
```

## Error Handlers Testing

In many cases, errors are handled by the user. They may want to perform some actions when an error
is thrown, and decide to propagate the error or continue with the flow’s execution.

We can have different tests for each of the following possibilities:

### On Error Continue

For example, lets look at the following mule code:

```xml
<flow name="retrieveKey">
    <os:retrieve key="#[payload.key]"/>
    <set-variable value="#[payload.id]" variableName="userId"/>
    <error-handler >
        <on-error-continue type="OS:INVALID_KEY">
            <set-payload value="#[{ message : 'Key is null'}]" />
        </on-error-continue>
    </error-handler>
</flow>
```

The `OS:INVALID_KEY` error is being handled and the execution continues with a specific payload.

Since the error is not propagated, the execution resumes and the event can be verified:

```xml
<munit:test name="retrieveNullKeyTest" description="Expect message when key is null">
    <munit:behavior>
        <munit:set-event>
            <munit:payload value="#[ { key: null}]" />
        </munit:set-event>
    </munit:behavior>
    <munit:execution>
        <flow-ref name="retrieveKey"/>
    </munit:execution>
    <munit:validation >
        <munit-tools:assert-that expression="#[payload.message]" is="#[MunitTools::equalTo('Key is null')]"/>
    </munit:validation>
</munit:test>
```

As you can see, in this case you don’t have to expect the `OS:INVALID_KEY` error type.

### On Error Propagate

For example, if the user’s code is the following:

```xml
<flow name="retrieveKey">
    <os:retrieve key="#[payload.key]"/>
    <set-variable value="#[payload.id]" variableName="userId"/>
    <error-handler >
        <on-error-propagate type="OS:INVALID_KEY">
            <raise-error type="APP:NULL_KEY"/>
        </on-error-propagate>
    </error-handler>
</flow>
```

The `OS:INVALID_KEY` error is being handled and the error `APP:NULL_KEY` is raised.

Since the test will fail with the raised custom error type, the test should expect it:

```xml
<munit:test name="retrieveNullKeyTest" description="Expect APP:NULL_KEY is raised" expectedErrorType="APP:NULL_KEY">
    <munit:behavior>
        <munit:set-event>
            <munit:payload value="#[ { key: null}]" />
        </munit:set-event>
    </munit:behavior>
    <munit:execution>
        <flow-ref name="retrieveKey"/>
    </munit:execution>
</munit:test>
```

## Mock Errors

When you don’t want to trigger manually an error on a component (like the examples above), but you
only want to make the processor fail with a specific error, you can use the `error` parameter of the
mock-when processor.

For example, if the user’s code is the following:

```xml
<flow name="requestFlow">
    <http:request method="GET" config-ref="HTTP_Request_configuration"/>
    <set-variable value="#[payload.id]" variableName="userId"/>
    <error-handler >
        <on-error-continue type="HTTP:CONNECTIVITY">
            <logger level="ERROR" message="AN ERROR OCCURRED"/>
        </on-error-continue>
    </error-handler>
</flow>
```

and you want to make the `http:request` fail with an `HTTP:CONNECTIVITY` error and also check that
the logger was actually executed, the test may look something like this:

Mock Error with On Error Continue

```xml
<munit:test name="requestFlowTest" description="Mock CONNECTIVITY error" >
    <munit:behavior >
        <munit-tools:mock-when processor="http:request">
            <munit-tools:then-return >
                <munit-tools:error typeId="HTTP:CONNECTIVITY" />
            </munit-tools:then-return>
        </munit-tools:mock-when>
    </munit:behavior>
    <munit:execution >
        <flow-ref name="requestFlow"/>
    </munit:execution>
    <munit:validation >
        <munit-tools:verify-call processor="mule:logger"/>
    </munit:validation>
</munit:test>
```

If the On Error scope is an `on-error-propagate`, the verifications won’t be executed since the flow
will propagate the error and fail, then the `validation` section of the test will be skipped.

In this case the error could be caught with a try scope and then the verifications can be performed:

Mock Error with On Error Propagate

```xml
<munit:test name="requestFlowTest" description="Mock CONNECTIVITY error" >
    <munit:behavior >
        <munit-tools:mock-when processor="http:request">
            <munit-tools:then-return >
                <munit-tools:error typeId="HTTP:CONNECTIVITY" />
            </munit-tools:then-return>
        </munit-tools:mock-when>
    </munit:behavior>
    <munit:execution >
        <try>
            <flow-ref name="requestFlow"/>
            <error-handler >
                <on-error-continue type="HTTP:CONNECTIVITY"/>
            </error-handler>
        </try>
    </munit:execution>
    <munit:validation >
        <munit-tools:verify-call processor="mule:logger"/>
    </munit:validation>
</munit:test>
```

## Set an Event with an Error

When extracting error handling logic into a separated flow or sub flow, the input event must have an
error that can be used in the error handling logic.

For example, lets look at the following mule code:

```xml
<flow name="retrieveFlow">
    <os:retrieve key="#[payload.key]"/>
    <error-handler >
        <on-error-continue>
            <flow-ref name="error-handlingSub_Flow"/>
        </on-error-continue>
    </error-handler>
</flow>

<sub-flow name="error-handlingSub_Flow">
    <logger level="INFO" message="#['Execution failed with: $(error.description)']"/>
</sub-flow>
```

If you wish to test the subFlow independently, you will need to set an error in the event.

The test may look something like this:

Set Error in the Event

```xml
<munit:test name="error_handlingSub_FlowTest" description="Test subFlow" >
    <munit:behavior >
        <munit:set-event>
            <munit:error id="OS:INVALID_KEY" exception="#[java!java::lang::Exception::new('Invalid Key')]"/>
        </munit:set-event>
    </munit:behavior>
    <munit:execution >
        <flow-ref name="error-handlingSub_Flow"/>
    </munit:execution>
    <munit:validation >
        <munit-tools:verify-call processor="mule:logger">
            <munit-tools:with-attributes >
                <munit-tools:with-attribute attributeName="message" whereValue="#['Execution failed with: Invalid Key']" />
            </munit-tools:with-attributes>
        </munit-tools:verify-call>
    </munit:validation>
</munit:test>
```

## See Also

- [Mock When Event Processor](https://docs.mulesoft.com/munit/latest/mock-event-processor)

- [Set Event Processor](https://docs.mulesoft.com/munit/latest/set-event-processor)

- [Verify Event Processor](https://docs.mulesoft.com/munit/latest/verify-event-processor)

<!-- document id=6850140ceb54af4f85c8305b5dc189d3065d123f143b1deb5667c412bc72057e url=/mulesoft/current/en-us/munit/2.3/domain-based-application-cookbook.md -->

---
product: MUnit
version: 2.3
---

# Test Domain-Based Applications

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

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

![domain munit example](/mulesoft/current/en-us/munit/2.3/_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/2.3/_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/2.3/_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 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

![munit domain sample](/mulesoft/current/en-us/munit/2.3/_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.

<!-- document id=0b12dbef2e1e1fc727820648183a72bc02d8a6f1664dca058be4744f37e5ccaa url=/mulesoft/current/en-us/munit/3.6/domain-based-application-cookbook.md -->

---
product: MUnit
version: 3.6
---

# Test 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

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

![domain munit example](/mulesoft/current/en-us/munit/3.6/_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/3.6/_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/3.6/_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 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

![munit domain sample](/mulesoft/current/en-us/munit/3.6/_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.

<!-- document id=7533284afaed1f0c7468605b2b461fadedfb2ce7c50fd414fa5ee42e6b523b96 url=/mulesoft/current/en-us/munit/latest/domain-based-application-cookbook.md -->

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

<!-- document id=a4016949ca484a12303a464365eebdaebcf55766cebb25747ace701d04ce570a url=/mulesoft/current/en-us/munit/latest/use-environment-properties-on-tests-cookbook.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# Test MUnit Flows with Environment Properties

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

Configure environment-specific properties in MUnit tests by extracting HTTP configuration values
into separate properties files for each environment. Use the MUnit Maven plugin to load the correct
properties file when running tests against a QA or production API endpoint.

Assume that you have the following flow that obtains data from an external API and you need to
consume it from a test environment when executing your MUnit tests:

```xml
<http:request-config name="HTTP_Request_configuration">
	<http:request-connection host="sampleapi.com/api/v1/" port="80"/>
</http:request-config>
<flow name="requestApiFlow">
	<http:request method="GET" config-ref="HTTP_Request_configuration" path="/employee"/>
</flow>
```

To consume data from a QA API endpoint when running your MUnit tests:

1.  Extract the HTTP Configuration values into a properties file for each environment where you will
    execute the validations. Those properties files must go under `src/main/resources`:

    prod.properties

    ```xml
    http.host=dummy.restapiexample.com/api/v1/
    http.port=80
    ```

    qa.properties

    ```xml
    http.host=dummy.qax.restapiexample.com/api/v1/
    http.port=8081
    ```

    You can set a properties file for each one of your environments.

2.  Use a `configuration-properties` global configuration in your configuration file to load
    environment properties from the previously created file:

    ```xml
     <configuration-properties file="${mule-env}.properties"/>
    ```

3.  Replace the HTTP configuration with placeholders matching the variables defined in the
    properties file:

    ```xml
    <http:request-config name="HTTP_Request_configuration">
    	<http:request-connection host="${http.host}" port="${http.port}"/>
    </http:request-config>
    <flow name="requestApiFlow">
    	<http:request method="GET" config-ref="HTTP_Request_configuration" path="/employee"/>
    </flow>
    ```

4.  Define an environment variable in the MUnit Maven plugin:

    ```xml
     <configuration>
         ...
         <environmentVariables>
             <mule-env>qa</mule-env>
         </environmentVariables>
         ...
     </configuration>
    ```

    During the execution of the MUnit tests, MUnit loads the properties from the `qa` properties
    file and connects to your test environment.

<!-- document id=f411ef20eed3aedaa2bea42c2812e51a1f592fae4030a727f3c5ab27490cfc25 url=/mulesoft/current/en-us/munit/latest/test-processor-that-uses-target-variable.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# Test MUnit Processors That Use Target Variables

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

When testing a processor that stores its result in a target variable in MUnit, assert the content of
the stored variable rather than the payload. If you mock the processor, define the target variable
value in the mock configuration.

## Example Test of a Target Variable from an HTTP Request Operation

Consider a Mule application with the following XML configuration:

```xml
<http:listener-config name="HTTP_Listener_config" doc:name="HTTP Listener config" >
  <http:listener-connection host="0.0.0.0" port="8081" />
</http:listener-config>
<http:request-config name="HTTP_Request_configuration" doc:name="HTTP Request configuration" />

<flow name="targetVariableTestFlow" >
  <http:listener doc:name="Listener" config-ref="HTTP_Listener_config" path="/test"/>
  <http:request
    method="GET"
    doc:name="Request"
    config-ref="HTTP_Request_configuration"
    target="httpResponse"
    targetValue="#[message]"
    url="http://www.mulesoft.com"/>
  <logger level="INFO" doc:name="Logger" message="#[vars.httpResponse]"/>
</flow>
```

When the HTTP listener receives a request, the app makes an HTTP request and the processor stores
the received HTTP response in a target variable called `httpResponse`.

You can create an MUnit test to assert that the stored variable contains, for example, a `200` HTTP
status code:

```xml
<munit:test name="test-target-variable-targetVariableTestFlowTest" description="Test">
  <munit:execution >
    <flow-ref doc:name="Flow-ref to targetVariableTestFlow" name="targetVariableTestFlow"/>
  </munit:execution>
  <munit:validation >
    <munit-tools:assert-that doc:name="Assert that" expression="#[vars.httpResponse.attributes.statusCode]" is="#[MunitTools::equalTo(200)]"/>
  </munit:validation>
</munit:test>
```

If you want to test the behavior of this app without making the HTTP request, you can mock the
processor and the stored target variable.

### Mock a Processor That Stores Data in a Target Variable

The following test mocks the HTTP request and the resulting target variable from the previous Mule
app example, and then asserts that the stored HTTP status code is `200`:

```xml
<munit:test name="test-target-variable-targetVariableTestFlowTest" description="Test">
  <munit:behavior >
    <munit-tools:mock-when doc:name="Mock when HTTP response" processor="http:request">
      <munit-tools:with-attributes >
        <munit-tools:with-attribute attributeName='#["doc:name"]' whereValue='#["Request"]' />
      </munit-tools:with-attributes>
      <munit-tools:then-return >
        <munit-tools:variables >
          <munit-tools:variable key="#['httpResponse']" value='#[{"attributes":{"statusCode":200}}]' />
        </munit-tools:variables>
      </munit-tools:then-return>
    </munit-tools:mock-when>
  </munit:behavior>
  <munit:execution >
    <flow-ref doc:name="Flow-ref to targetVariableTestFlow" name="targetVariableTestFlow"/>
  </munit:execution>
  <munit:validation >
    <munit-tools:assert-that doc:name="Assert that" expression="#[vars.httpResponse.attributes.statusCode]" is="#[MunitTools::equalTo(200)]"/>
  </munit:validation>
</munit:test>
```

## See Also

- [Mock When Event Processor](https://docs.mulesoft.com/munit/latest/mock-event-processor)

- [MUnit Matchers](https://docs.mulesoft.com/munit/latest/munit-matchers)

<!-- document id=218bbc33568499a9c1b9dc280796b0cdc3371c984b427ea647b3a8dfe9de8bb4 url=/mulesoft/current/en-us/munit/2.3/test-recorder.md -->

---
product: MUnit
version: 2.3
---

# Test Recorder in Studio

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

The Test Recorder enables you to record a processing flow and then configure a unit test based on
the captured event.

The test recorder captures real data as it goes through your application in Anypoint Studio. By
capturing the flow execution, MUnit can automatically generate an MUnit test so that you can
configure the necessary mocks and assertions for your test. See
[Recording a Test from an Exchange Example](https://docs.mulesoft.com/munit/2.3/test-recorder-examples) for a fully working example.

## Compatibility

The following table describes the product versions required to use the Test Recorder.

<table><colgroup><col> <col></colgroup><thead><tr><th>Product</th><th>Version</th></tr></thead><tbody><tr><td><div><div><p>Anypoint Studio</p></div></div></td><td><div><div><p>7.5.0 and later</p></div></div></td></tr><tr><td><div><div><p>MUnit</p></div></div></td><td><div><div><p>2.2.5 and later</p></div></div></td></tr><tr><td><div><div><p>MUnit Anypoint Studio Plugin</p></div></div></td><td><div><div><p>2.5.0 and later</p></div></div></td></tr><tr><td><div><div><p>Mule runtime engine</p></div></div></td><td><div><div><p>4.3.0 and later</p></div></div></td></tr></tbody></table>

## Limitations

The test recorder has the following limitations when you create MUnit tests:

- You cannot create tests for flows with Mule errors raised inside the flow or already existing in
  the incoming event, even if an **on error continue** error handler controls them.

- A recorded flow execution ends successfully, but the result does not reach its destination because
  the application is killed.

- Your validations fail every time your test runs if you configure `spy` or `assert` processors to
  assert values for random data, time-dependent information (such as timestamps), or values
  resulting from parallel processes, because those values change in every execution.

- Mocking values resulting from parallel processes causes a mixture of real and mocked data that
  compromises the execution of the processors that follow in your test.

- Although the recorder supports data iteration in the flow, such as recursions or loops, it does
  not support cases in which the structure of the data being tested changes inside the iteration.

- The recorder does not support mocking a message before or inside a `foreach` processor.

- When using the Test Recorder to generate a test over your flow, you can only mock parameters
  included in your flow. You cannot mock parameters in sub-flows or in referenced flows through the
  Test Recorder UI. If you need to mock parameters in sub-flows of any other process in the project,
  you can modify the mocking component after creating the test.

## See Also

- [Recording a Test from an Exchange Example](https://docs.mulesoft.com/munit/2.3/test-recorder-examples)

- [Mocking a Message Before and Inside a Foreach Processor](https://docs.mulesoft.com/munit/2.3/mock-before-after-foreach-cookbook)

<!-- document id=c8aa4c8e5aa4972f0214a1df7af56e2064db44e1d7d1b607d59cb5d4977b945d url=/mulesoft/current/en-us/munit/3.6/test-recorder.md -->

---
product: MUnit
version: 3.6
---

# Test Recorder in Studio

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

The Test Recorder enables you to record a processing flow and then configure a unit test based on
the captured event.

The test recorder captures real data as it goes through your application in Anypoint Studio. By
capturing the flow execution, MUnit can automatically generate an MUnit test so that you can
configure the necessary mocks and assertions for your test. See
[Recording a Test from an Exchange Example](https://docs.mulesoft.com/munit/3.6/test-recorder-examples) for a fully working example.

## Compatibility

The following table describes the product versions required to use the Test Recorder.

<table><colgroup><col> <col></colgroup><thead><tr><th>Product</th><th>Version</th></tr></thead><tbody><tr><td><div><div><p>Anypoint Studio</p></div></div></td><td><div><div><p>7.5.0 and later</p></div></div></td></tr><tr><td><div><div><p>MUnit</p></div></div></td><td><div><div><p>2.2.5 and later</p></div></div></td></tr><tr><td><div><div><p>MUnit Anypoint Studio Plugin</p></div></div></td><td><div><div><p>2.5.0 and later</p></div></div></td></tr><tr><td><div><div><p>Mule runtime engine</p></div></div></td><td><div><div><p>4.3.0 and later</p></div></div></td></tr></tbody></table>

## Limitations

The test recorder has the following limitations when you create MUnit tests:

- You cannot create tests for flows with Mule errors raised inside the flow or already existing in
  the incoming event, even if an **on error continue** error handler controls them.

- A recorded flow execution ends successfully, but the result does not reach its destination because
  the application is killed.

- Your validations fail every time your test runs if you configure `spy` or `assert` processors to
  assert values for random data, time-dependent information (such as timestamps), or values
  resulting from parallel processes, because those values change in every execution.

- Mocking values resulting from parallel processes causes a mixture of real and mocked data that
  compromises the execution of the processors that follow in your test.

- Although the recorder supports data iteration in the flow, such as recursions or loops, it does
  not support cases in which the structure of the data being tested changes inside the iteration.

- The recorder does not support mocking a message before or inside a `foreach` processor.

- When using the Test Recorder to generate a test over your flow, you can only mock parameters
  included in your flow. You cannot mock parameters in sub-flows or in referenced flows through the
  Test Recorder UI. If you need to mock parameters in sub-flows of any other process in the project,
  you can modify the mocking component after creating the test.

## See Also

- [Recording a Test from an Exchange Example](https://docs.mulesoft.com/munit/3.6/test-recorder-examples)

- [Mocking a Message Before and Inside a Foreach Processor](https://docs.mulesoft.com/munit/3.6/mock-before-after-foreach-cookbook)

<!-- document id=0a1dc0ce0a26e97e38c32aa8ff67f5488b0eb001ea48e5f855374328b8367668 url=/mulesoft/current/en-us/munit/2.3/test-flow-with-scheduler-cookbook.md -->

---
product: MUnit
version: 2.3
---

# Testing a Flow with a Scheduler Source

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

Assume that you want to both test the following flow triggered by a Scheduler component and validate
that your flow is being triggered correctly:

```xml
<flow name="schedulerFlow">
    <scheduler>
        <scheduling-strategy >
            <fixed-frequency frequency="10" timeUnit="SECONDS"/>
        </scheduling-strategy>
    </scheduler>
    <set-payload value="#['test poll']"/>
</flow>
```

1.  Enable flow sources.  
    Because MUnit does not start any of the flow sources (such as triggers or listeners), you must
    configure which flow sources start for your tests.

    In this example, you enable the flow that contains the Scheduler:

    ```xml
    <munit:test name="test-schedulerFlowTest">
        <munit:enable-flow-sources>
            <munit:enable-flow-source value="schedulerFlow"/>
        </munit:enable-flow-sources>
    </munit:test>
    ```

2.  Verify that flow execution is triggered by the Scheduler.  
    To verify that the processors inside your flow are being triggered, use the
    `munit-tools:verify-call` processor.

    Wrap `munit-tools:verify-call` inside an `until-successful` to shorten processing time when the
    Scheduler is not operating when you want to test.

    The following example validates three times that the payload was executed at least once during
    the test.

    ```xml
    <munit:execution>
        <until-successful maxRetries="3" millisBetweenRetries="100">
            <munit-tools:verify-call processor="set-payload" atLeast="1">
                <munit-tools:with-attributes >
                    <munit-tools:with-attribute whereValue="#['test poll']" attributeName="value" />
                </munit-tools:with-attributes>
            </munit-tools:verify-call>
        </until-successful>
    </munit:execution>
    ```

## See Also

- [Enable Flow Sources](https://docs.mulesoft.com/munit/2.3/enable-flow-sources-concept)

- [Verify Event Processor](https://docs.mulesoft.com/munit/2.3/verify-event-processor)

<!-- document id=e7d69a94454224926ccbc41749027a289f3b1fd7b92287c675d444f45fdf39a3 url=/mulesoft/current/en-us/munit/3.6/test-flow-with-scheduler-cookbook.md -->

---
product: MUnit
version: 3.6
---

# Testing a Flow with a Scheduler Source

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

Assume that you want to both test the following flow triggered by a Scheduler component and validate
that your flow is being triggered correctly:

```xml
<flow name="schedulerFlow">
    <scheduler>
        <scheduling-strategy >
            <fixed-frequency frequency="10" timeUnit="SECONDS"/>
        </scheduling-strategy>
    </scheduler>
    <set-payload value="#['test poll']"/>
</flow>
```

1.  Enable flow sources.  
    Because MUnit does not start any of the flow sources (such as triggers or listeners), you must
    configure which flow sources start for your tests.

    In this example, you enable the flow that contains the Scheduler:

    ```xml
    <munit:test name="test-schedulerFlowTest">
        <munit:enable-flow-sources>
            <munit:enable-flow-source value="schedulerFlow"/>
        </munit:enable-flow-sources>
    </munit:test>
    ```

2.  Verify that flow execution is triggered by the Scheduler.  
    To verify that the processors inside your flow are being triggered, use the
    `munit-tools:verify-call` processor.

    Wrap `munit-tools:verify-call` inside an `until-successful` to shorten processing time when the
    Scheduler is not operating when you want to test.

    The following example validates three times that the payload was executed at least once during
    the test.

    ```xml
    <munit:execution>
        <until-successful maxRetries="3" millisBetweenRetries="100">
            <munit-tools:verify-call processor="set-payload" atLeast="1">
                <munit-tools:with-attributes >
                    <munit-tools:with-attribute whereValue="#['test poll']" attributeName="value" />
                </munit-tools:with-attributes>
            </munit-tools:verify-call>
        </until-successful>
    </munit:execution>
    ```

## See Also

- [Enable Flow Sources](https://docs.mulesoft.com/munit/3.6/enable-flow-sources-concept)

- [Verify Event Processor](https://docs.mulesoft.com/munit/3.6/verify-event-processor)

<!-- document id=249ecab66d83444291c4f140f764eb5ecfa91b91b9e8ca456856f3af0dd245c8 url=/mulesoft/current/en-us/munit/2.3/test-processor-that-uses-target-variable.md -->

---
product: MUnit
version: 2.3
---

# Testing a Processor That Stores Data in a Target Variable

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

When you test a processor that stores its result in a target variable, ensure that the assertions
check the content of the stored variable. If you mock the processor, define a value for the target
variable.

## Example Test of a Target Variable from an HTTP Request Operation

Consider a Mule application with the following XML configuration:

```xml
<http:listener-config name="HTTP_Listener_config" doc:name="HTTP Listener config" >
  <http:listener-connection host="0.0.0.0" port="8081" />
</http:listener-config>
<http:request-config name="HTTP_Request_configuration" doc:name="HTTP Request configuration" />

<flow name="targetVariableTestFlow" >
  <http:listener doc:name="Listener" config-ref="HTTP_Listener_config" path="/test"/>
  <http:request
    method="GET"
    doc:name="Request"
    config-ref="HTTP_Request_configuration"
    target="httpResponse"
    targetValue="#[message]"
    url="http://www.mulesoft.com"/>
  <logger level="INFO" doc:name="Logger" message="#[vars.httpResponse]"/>
</flow>
```

When the HTTP listener receives a request, the app makes an HTTP request and the processor stores
the received HTTP response in a target variable called `httpResponse`.

You can create an MUnit test to assert that the stored variable contains, for example, a `200` HTTP
status code:

```xml
<munit:test name="test-target-variable-targetVariableTestFlowTest" description="Test">
  <munit:execution >
    <flow-ref doc:name="Flow-ref to targetVariableTestFlow" name="targetVariableTestFlow"/>
  </munit:execution>
  <munit:validation >
    <munit-tools:assert-that doc:name="Assert that" expression="#[vars.httpResponse.attributes.statusCode]" is="#[MunitTools::equalTo(200)]"/>
  </munit:validation>
</munit:test>
```

If you want to test the behavior of this app without making the HTTP request, you can mock the
processor and the stored target variable.

### Mock a Processor that Stores Data in a Target Variable

The following test mocks the HTTP request and the resulting target variable from the previous Mule
app example, and then asserts that the stored HTTP status code is `200`:

```xml
<munit:test name="test-target-variable-targetVariableTestFlowTest" description="Test">
  <munit:behavior >
    <munit-tools:mock-when doc:name="Mock when HTTP response" processor="http:request">
      <munit-tools:with-attributes >
        <munit-tools:with-attribute attributeName='#["doc:name"]' whereValue='#["Request"]' />
      </munit-tools:with-attributes>
      <munit-tools:then-return >
        <munit-tools:variables >
          <munit-tools:variable key="#['httpResponse']" value='#[{"attributes":{"statusCode":200}}]' />
        </munit-tools:variables>
      </munit-tools:then-return>
    </munit-tools:mock-when>
  </munit:behavior>
  <munit:execution >
    <flow-ref doc:name="Flow-ref to targetVariableTestFlow" name="targetVariableTestFlow"/>
  </munit:execution>
  <munit:validation >
    <munit-tools:assert-that doc:name="Assert that" expression="#[vars.httpResponse.attributes.statusCode]" is="#[MunitTools::equalTo(200)]"/>
  </munit:validation>
</munit:test>
```

## See Also

- [Mock When Event Processor](https://docs.mulesoft.com/munit/2.3/mock-event-processor)

- [MUnit Matchers](https://docs.mulesoft.com/munit/2.3/munit-matchers)

<!-- document id=297f806738214c88807ad5e61c87de50f5fb6752cbacc781ddcd9a19831c69e0 url=/mulesoft/current/en-us/munit/3.6/test-processor-that-uses-target-variable.md -->

---
product: MUnit
version: 3.6
---

# Testing a Processor That Stores Data in a Target Variable

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

When you test a processor that stores its result in a target variable, ensure that the assertions
check the content of the stored variable. If you mock the processor, define a value for the target
variable.

## Example Test of a Target Variable from an HTTP Request Operation

Consider a Mule application with the following XML configuration:

```xml
<http:listener-config name="HTTP_Listener_config" doc:name="HTTP Listener config" >
  <http:listener-connection host="0.0.0.0" port="8081" />
</http:listener-config>
<http:request-config name="HTTP_Request_configuration" doc:name="HTTP Request configuration" />

<flow name="targetVariableTestFlow" >
  <http:listener doc:name="Listener" config-ref="HTTP_Listener_config" path="/test"/>
  <http:request
    method="GET"
    doc:name="Request"
    config-ref="HTTP_Request_configuration"
    target="httpResponse"
    targetValue="#[message]"
    url="http://www.mulesoft.com"/>
  <logger level="INFO" doc:name="Logger" message="#[vars.httpResponse]"/>
</flow>
```

When the HTTP listener receives a request, the app makes an HTTP request and the processor stores
the received HTTP response in a target variable called `httpResponse`.

You can create an MUnit test to assert that the stored variable contains, for example, a `200` HTTP
status code:

```xml
<munit:test name="test-target-variable-targetVariableTestFlowTest" description="Test">
  <munit:execution >
    <flow-ref doc:name="Flow-ref to targetVariableTestFlow" name="targetVariableTestFlow"/>
  </munit:execution>
  <munit:validation >
    <munit-tools:assert-that doc:name="Assert that" expression="#[vars.httpResponse.attributes.statusCode]" is="#[MunitTools::equalTo(200)]"/>
  </munit:validation>
</munit:test>
```

If you want to test the behavior of this app without making the HTTP request, you can mock the
processor and the stored target variable.

### Mock a Processor that Stores Data in a Target Variable

The following test mocks the HTTP request and the resulting target variable from the previous Mule
app example, and then asserts that the stored HTTP status code is `200`:

```xml
<munit:test name="test-target-variable-targetVariableTestFlowTest" description="Test">
  <munit:behavior >
    <munit-tools:mock-when doc:name="Mock when HTTP response" processor="http:request">
      <munit-tools:with-attributes >
        <munit-tools:with-attribute attributeName='#["doc:name"]' whereValue='#["Request"]' />
      </munit-tools:with-attributes>
      <munit-tools:then-return >
        <munit-tools:variables >
          <munit-tools:variable key="#['httpResponse']" value='#[{"attributes":{"statusCode":200}}]' />
        </munit-tools:variables>
      </munit-tools:then-return>
    </munit-tools:mock-when>
  </munit:behavior>
  <munit:execution >
    <flow-ref doc:name="Flow-ref to targetVariableTestFlow" name="targetVariableTestFlow"/>
  </munit:execution>
  <munit:validation >
    <munit-tools:assert-that doc:name="Assert that" expression="#[vars.httpResponse.attributes.statusCode]" is="#[MunitTools::equalTo(200)]"/>
  </munit:validation>
</munit:test>
```

## See Also

- [Mock When Event Processor](https://docs.mulesoft.com/munit/3.6/mock-event-processor)

- [MUnit Matchers](https://docs.mulesoft.com/munit/3.6/munit-matchers)

<!-- document id=2b98c45686832ec22e4cf1687a243ec692730bf1906aa8345af7b2b232ee4bea url=/mulesoft/current/en-us/munit/2.3/test-mock-errors-cookbook.md -->

---
product: MUnit
version: 2.3
---

# Testing and Mocking Errors

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

## Expect an Error in your Test

During the execution of a flow, components may throw errors which might be expected for the use case
being tested. In these cases, you want to specify that your test expects a particular error type or
exception.

For example, lets look at the following Mule code:

```xml
<flow name="retrieveKey">
    <os:retrieve key="#[payload.key]"/>
    <set-variable value="#[payload.id]" variableName="userId"/>
</flow>
```

The key is taken from the payload and if the key is `null`, the Object Store connector will throw an
error with `OS:INVALID_KEY` error type.

The test to validate this case would be something like this:

```xml
<munit:test name="retrieveNullKeyTest" description="Expect error when key is null" expectedErrorType="OS:INVALID_KEY">
    <munit:behavior>
        <munit:set-event>
            <munit:payload value="#[ { key: null}]" />
        </munit:set-event>
    </munit:behavior>
    <munit:execution>
        <flow-ref name="retrieveKey"/>
    </munit:execution>
</munit:test>
```

## Error Handlers Testing

In many cases, errors are handled by the user. They may want to perform some actions when an error
is thrown, and decide to propagate the error or continue with the flow’s execution.

We can have different tests for each of the following possibilities:

### On Error Continue

For example, lets look at the following mule code:

```xml
<flow name="retrieveKey">
    <os:retrieve key="#[payload.key]"/>
    <set-variable value="#[payload.id]" variableName="userId"/>
    <error-handler >
        <on-error-continue type="OS:INVALID_KEY">
            <set-payload value="#[{ message : 'Key is null'}]" />
        </on-error-continue>
    </error-handler>
</flow>
```

The `OS:INVALID_KEY` error is being handled and the execution continues with a specific payload.

Since the error is not propagated, the execution resumes and the event can be verified:

```xml
<munit:test name="retrieveNullKeyTest" description="Expect message when key is null">
    <munit:behavior>
        <munit:set-event>
            <munit:payload value="#[ { key: null}]" />
        </munit:set-event>
    </munit:behavior>
    <munit:execution>
        <flow-ref name="retrieveKey"/>
    </munit:execution>
    <munit:validation >
        <munit-tools:assert-that expression="#[payload.message]" is="#[MunitTools::equalTo('Key is null')]"/>
    </munit:validation>
</munit:test>
```

As you can see, in this case you don’t have to expect the `OS:INVALID_KEY` error type.

### On Error Propagate

For example, if the user’s code is the following:

```xml
<flow name="retrieveKey">
    <os:retrieve key="#[payload.key]"/>
    <set-variable value="#[payload.id]" variableName="userId"/>
    <error-handler >
        <on-error-propagate type="OS:INVALID_KEY">
            <raise-error type="APP:NULL_KEY"/>
        </on-error-propagate>
    </error-handler>
</flow>
```

The `OS:INVALID_KEY` error is being handled and the error `APP:NULL_KEY` is raised.

Since the test will fail with the raised custom error type, the test should expect it:

```xml
<munit:test name="retrieveNullKeyTest" description="Expect APP:NULL_KEY is raised" expectedErrorType="APP:NULL_KEY">
    <munit:behavior>
        <munit:set-event>
            <munit:payload value="#[ { key: null}]" />
        </munit:set-event>
    </munit:behavior>
    <munit:execution>
        <flow-ref name="retrieveKey"/>
    </munit:execution>
</munit:test>
```

## Mock Errors

When you don’t want to trigger manually an error on a component (like the examples above), but you
only want to make the processor fail with a specific error, you can use the `error` parameter of the
mock-when processor.

For example, if the user’s code is the following:

```xml
<flow name="requestFlow">
    <http:request method="GET" config-ref="HTTP_Request_configuration"/>
    <set-variable value="#[payload.id]" variableName="userId"/>
    <error-handler >
        <on-error-continue type="HTTP:CONNECTIVITY">
            <logger level="ERROR" message="AN ERROR OCCURRED"/>
        </on-error-continue>
    </error-handler>
</flow>
```

and you want to make the `http:request` fail with an `HTTP:CONNECTIVITY` error and also check that
the logger was actually executed, the test may look something like this:

Mock Error with On Error Continue

```xml
<munit:test name="requestFlowTest" description="Mock CONNECTIVITY error" >
    <munit:behavior >
        <munit-tools:mock-when processor="http:request">
            <munit-tools:then-return >
                <munit-tools:error typeId="HTTP:CONNECTIVITY" />
            </munit-tools:then-return>
        </munit-tools:mock-when>
    </munit:behavior>
    <munit:execution >
        <flow-ref name="requestFlow"/>
    </munit:execution>
    <munit:validation >
        <munit-tools:verify-call processor="mule:logger"/>
    </munit:validation>
</munit:test>
```

If the On Error scope is an `on-error-propagate`, the verifications won’t be executed since the flow
will propagate the error and fail, then the `validation` section of the test will be skipped.

In this case the error could be caught with a try scope and then the verifications can be performed:

Mock Error with On Error Propagate

```xml
<munit:test name="requestFlowTest" description="Mock CONNECTIVITY error" >
    <munit:behavior >
        <munit-tools:mock-when processor="http:request">
            <munit-tools:then-return >
                <munit-tools:error typeId="HTTP:CONNECTIVITY" />
            </munit-tools:then-return>
        </munit-tools:mock-when>
    </munit:behavior>
    <munit:execution >
        <try>
            <flow-ref name="requestFlow"/>
            <error-handler >
                <on-error-continue type="HTTP:CONNECTIVITY"/>
            </error-handler>
        </try>
    </munit:execution>
    <munit:validation >
        <munit-tools:verify-call processor="mule:logger"/>
    </munit:validation>
</munit:test>
```

## Set an Event with an Error

When extracting error handling logic into a separated flow or sub flow, the input event must have an
error that can be used in the error handling logic.

For example, lets look at the following mule code:

```xml
<flow name="retrieveFlow">
    <os:retrieve key="#[payload.key]"/>
    <error-handler >
        <on-error-continue>
            <flow-ref name="error-handlingSub_Flow"/>
        </on-error-continue>
    </error-handler>
</flow>

<sub-flow name="error-handlingSub_Flow">
    <logger level="INFO" message="#['Execution failed with: $(error.description)']"/>
</sub-flow>
```

If you wish to test the subFlow independently, you will need to set an error in the event.

The test may look something like this:

Set Error in the Event

```xml
<munit:test name="error_handlingSub_FlowTest" description="Test subFlow" >
    <munit:behavior >
        <munit:set-event>
            <munit:error id="OS:INVALID_KEY" exception="#[java!java::lang::Exception::new('Invalid Key')]"/>
        </munit:set-event>
    </munit:behavior>
    <munit:execution >
        <flow-ref name="error-handlingSub_Flow"/>
    </munit:execution>
    <munit:validation >
        <munit-tools:verify-call processor="mule:logger">
            <munit-tools:with-attributes >
                <munit-tools:with-attribute attributeName="message" whereValue="#['Execution failed with: Invalid Key']" />
            </munit-tools:with-attributes>
        </munit-tools:verify-call>
    </munit:validation>
</munit:test>
```

## See Also

- [Mock When Event Processor](https://docs.mulesoft.com/munit/2.3/mock-event-processor)

- [Set Event Processor](https://docs.mulesoft.com/munit/2.3/set-event-processor)

- [Verify Event Processor](https://docs.mulesoft.com/munit/2.3/verify-event-processor)

<!-- document id=a83b5cac43bab3415ed0d7f3bdf123b478d4b8879986ed303e673a4b6a93c025 url=/mulesoft/current/en-us/munit/3.6/test-mock-errors-cookbook.md -->

---
product: MUnit
version: 3.6
---

# Testing and Mocking Errors

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

## Expect an Error in your Test

During the execution of a flow, components may throw errors which might be expected for the use case
being tested. In these cases, you want to specify that your test expects a particular error type or
exception.

For example, lets look at the following Mule code:

```xml
<flow name="retrieveKey">
    <os:retrieve key="#[payload.key]"/>
    <set-variable value="#[payload.id]" variableName="userId"/>
</flow>
```

The key is taken from the payload and if the key is `null`, the Object Store connector will throw an
error with `OS:INVALID_KEY` error type.

The test to validate this case would be something like this:

```xml
<munit:test name="retrieveNullKeyTest" description="Expect error when key is null" expectedErrorType="OS:INVALID_KEY">
    <munit:behavior>
        <munit:set-event>
            <munit:payload value="#[ { key: null}]" />
        </munit:set-event>
    </munit:behavior>
    <munit:execution>
        <flow-ref name="retrieveKey"/>
    </munit:execution>
</munit:test>
```

## Error Handlers Testing

In many cases, errors are handled by the user. They may want to perform some actions when an error
is thrown, and decide to propagate the error or continue with the flow’s execution.

We can have different tests for each of the following possibilities:

### On Error Continue

For example, lets look at the following mule code:

```xml
<flow name="retrieveKey">
    <os:retrieve key="#[payload.key]"/>
    <set-variable value="#[payload.id]" variableName="userId"/>
    <error-handler >
        <on-error-continue type="OS:INVALID_KEY">
            <set-payload value="#[{ message : 'Key is null'}]" />
        </on-error-continue>
    </error-handler>
</flow>
```

The `OS:INVALID_KEY` error is being handled and the execution continues with a specific payload.

Since the error is not propagated, the execution resumes and the event can be verified:

```xml
<munit:test name="retrieveNullKeyTest" description="Expect message when key is null">
    <munit:behavior>
        <munit:set-event>
            <munit:payload value="#[ { key: null}]" />
        </munit:set-event>
    </munit:behavior>
    <munit:execution>
        <flow-ref name="retrieveKey"/>
    </munit:execution>
    <munit:validation >
        <munit-tools:assert-that expression="#[payload.message]" is="#[MunitTools::equalTo('Key is null')]"/>
    </munit:validation>
</munit:test>
```

As you can see, in this case you don’t have to expect the `OS:INVALID_KEY` error type.

### On Error Propagate

For example, if the user’s code is the following:

```xml
<flow name="retrieveKey">
    <os:retrieve key="#[payload.key]"/>
    <set-variable value="#[payload.id]" variableName="userId"/>
    <error-handler >
        <on-error-propagate type="OS:INVALID_KEY">
            <raise-error type="APP:NULL_KEY"/>
        </on-error-propagate>
    </error-handler>
</flow>
```

The `OS:INVALID_KEY` error is being handled and the error `APP:NULL_KEY` is raised.

Since the test will fail with the raised custom error type, the test should expect it:

```xml
<munit:test name="retrieveNullKeyTest" description="Expect APP:NULL_KEY is raised" expectedErrorType="APP:NULL_KEY">
    <munit:behavior>
        <munit:set-event>
            <munit:payload value="#[ { key: null}]" />
        </munit:set-event>
    </munit:behavior>
    <munit:execution>
        <flow-ref name="retrieveKey"/>
    </munit:execution>
</munit:test>
```

## Mock Errors

When you don’t want to trigger manually an error on a component (like the examples above), but you
only want to make the processor fail with a specific error, you can use the `error` parameter of the
mock-when processor.

For example, if the user’s code is the following:

```xml
<flow name="requestFlow">
    <http:request method="GET" config-ref="HTTP_Request_configuration"/>
    <set-variable value="#[payload.id]" variableName="userId"/>
    <error-handler >
        <on-error-continue type="HTTP:CONNECTIVITY">
            <logger level="ERROR" message="AN ERROR OCCURRED"/>
        </on-error-continue>
    </error-handler>
</flow>
```

and you want to make the `http:request` fail with an `HTTP:CONNECTIVITY` error and also check that
the logger was actually executed, the test may look something like this:

Mock Error with On Error Continue

```xml
<munit:test name="requestFlowTest" description="Mock CONNECTIVITY error" >
    <munit:behavior >
        <munit-tools:mock-when processor="http:request">
            <munit-tools:then-return >
                <munit-tools:error typeId="HTTP:CONNECTIVITY" />
            </munit-tools:then-return>
        </munit-tools:mock-when>
    </munit:behavior>
    <munit:execution >
        <flow-ref name="requestFlow"/>
    </munit:execution>
    <munit:validation >
        <munit-tools:verify-call processor="mule:logger"/>
    </munit:validation>
</munit:test>
```

If the On Error scope is an `on-error-propagate`, the verifications won’t be executed since the flow
will propagate the error and fail, then the `validation` section of the test will be skipped.

In this case the error could be caught with a try scope and then the verifications can be performed:

Mock Error with On Error Propagate

```xml
<munit:test name="requestFlowTest" description="Mock CONNECTIVITY error" >
    <munit:behavior >
        <munit-tools:mock-when processor="http:request">
            <munit-tools:then-return >
                <munit-tools:error typeId="HTTP:CONNECTIVITY" />
            </munit-tools:then-return>
        </munit-tools:mock-when>
    </munit:behavior>
    <munit:execution >
        <try>
            <flow-ref name="requestFlow"/>
            <error-handler >
                <on-error-continue type="HTTP:CONNECTIVITY"/>
            </error-handler>
        </try>
    </munit:execution>
    <munit:validation >
        <munit-tools:verify-call processor="mule:logger"/>
    </munit:validation>
</munit:test>
```

## Set an Event with an Error

When extracting error handling logic into a separated flow or sub flow, the input event must have an
error that can be used in the error handling logic.

For example, lets look at the following mule code:

```xml
<flow name="retrieveFlow">
    <os:retrieve key="#[payload.key]"/>
    <error-handler >
        <on-error-continue>
            <flow-ref name="error-handlingSub_Flow"/>
        </on-error-continue>
    </error-handler>
</flow>

<sub-flow name="error-handlingSub_Flow">
    <logger level="INFO" message="#['Execution failed with: $(error.description)']"/>
</sub-flow>
```

If you wish to test the subFlow independently, you will need to set an error in the event.

The test may look something like this:

Set Error in the Event

```xml
<munit:test name="error_handlingSub_FlowTest" description="Test subFlow" >
    <munit:behavior >
        <munit:set-event>
            <munit:error id="OS:INVALID_KEY" exception="#[java!java::lang::Exception::new('Invalid Key')]"/>
        </munit:set-event>
    </munit:behavior>
    <munit:execution >
        <flow-ref name="error-handlingSub_Flow"/>
    </munit:execution>
    <munit:validation >
        <munit-tools:verify-call processor="mule:logger">
            <munit-tools:with-attributes >
                <munit-tools:with-attribute attributeName="message" whereValue="#['Execution failed with: Invalid Key']" />
            </munit-tools:with-attributes>
        </munit-tools:verify-call>
    </munit:validation>
</munit:test>
```

## See Also

- [Mock When Event Processor](https://docs.mulesoft.com/munit/3.6/mock-event-processor)

- [Set Event Processor](https://docs.mulesoft.com/munit/3.6/set-event-processor)

- [Verify Event Processor](https://docs.mulesoft.com/munit/3.6/verify-event-processor)

<!-- document id=e5f1ce025a531ef744d9fa08118ee65b8a491d6d8cac4009875986f4fe26d188 url=/mulesoft/current/en-us/munit/2.3/use-environment-properties-on-tests-cookbook.md -->

---
product: MUnit
version: 2.3
---

# Testing with Environment Properties

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

Assume that you have the following flow that obtains data from an external API and you need to
consume it from a test environment when executing your MUnit tests:

```xml
<http:request-config name="HTTP_Request_configuration">
	<http:request-connection host="sampleapi.com/api/v1/" port="80"/>
</http:request-config>
<flow name="requestApiFlow">
	<http:request method="GET" config-ref="HTTP_Request_configuration" path="/employee"/>
</flow>
```

To consume data from a QA API endpoint when running your MUnit tests:

1.  Extract the HTTP Configuration values into a properties file for each environment where you will
    execute the validations. Those properties files must go under `src/main/resources`:

    prod.properties

    ```xml
    http.host=dummy.restapiexample.com/api/v1/
    http.port=80
    ```

    qa.properties

    ```xml
    http.host=dummy.qax.restapiexample.com/api/v1/
    http.port=8081
    ```

    You can set a properties file for each one of your environments.

2.  Use a `configuration-properties` global configuration in your configuration file to load
    environment properties from the previously created file:

    ```xml
     <configuration-properties file="${mule-env}.properties"/>
    ```

3.  Replace the HTTP configuration with placeholders matching the variables defined in the
    properties file:

    ```xml
    <http:request-config name="HTTP_Request_configuration">
    	<http:request-connection host="${http.host}" port="${http.port}"/>
    </http:request-config>
    <flow name="requestApiFlow">
    	<http:request method="GET" config-ref="HTTP_Request_configuration" path="/employee"/>
    </flow>
    ```

4.  Define an environment variable in the MUnit Maven plugin:

    ```xml
     <configuration>
         ...
         <environmentVariables>
             <mule-env>qa</mule-env>
         </environmentVariables>
         ...
     </configuration>
    ```

    During the execution of the MUnit tests, MUnit loads the properties from the `qa` properties
    file and connects to your test environment.

<!-- document id=c6aae9f9e0edfaa88e5c82024ebea0804e6b639f5f6be660619563e0b5cc8099 url=/mulesoft/current/en-us/munit/3.6/use-environment-properties-on-tests-cookbook.md -->

---
product: MUnit
version: 3.6
---

# Testing with Environment Properties

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

Assume that you have the following flow that obtains data from an external API and you need to
consume it from a test environment when executing your MUnit tests:

```xml
<http:request-config name="HTTP_Request_configuration">
	<http:request-connection host="sampleapi.com/api/v1/" port="80"/>
</http:request-config>
<flow name="requestApiFlow">
	<http:request method="GET" config-ref="HTTP_Request_configuration" path="/employee"/>
</flow>
```

To consume data from a QA API endpoint when running your MUnit tests:

1.  Extract the HTTP Configuration values into a properties file for each environment where you will
    execute the validations. Those properties files must go under `src/main/resources`:

    prod.properties

    ```xml
    http.host=dummy.restapiexample.com/api/v1/
    http.port=80
    ```

    qa.properties

    ```xml
    http.host=dummy.qax.restapiexample.com/api/v1/
    http.port=8081
    ```

    You can set a properties file for each one of your environments.

2.  Use a `configuration-properties` global configuration in your configuration file to load
    environment properties from the previously created file:

    ```xml
     <configuration-properties file="${mule-env}.properties"/>
    ```

3.  Replace the HTTP configuration with placeholders matching the variables defined in the
    properties file:

    ```xml
    <http:request-config name="HTTP_Request_configuration">
    	<http:request-connection host="${http.host}" port="${http.port}"/>
    </http:request-config>
    <flow name="requestApiFlow">
    	<http:request method="GET" config-ref="HTTP_Request_configuration" path="/employee"/>
    </flow>
    ```

4.  Define an environment variable in the MUnit Maven plugin:

    ```xml
     <configuration>
         ...
         <environmentVariables>
             <mule-env>qa</mule-env>
         </environmentVariables>
         ...
     </configuration>
    ```

    During the execution of the MUnit tests, MUnit loads the properties from the `qa` properties
    file and connects to your test environment.

<!-- document id=7b3accac81d90a7d968ece9cabfd736336b40ef5e41fd68bfb5d2c3e632ddf7d url=/mulesoft/current/en-us/munit/latest/utility-classes-cookbook.md -->

---
product: MUnit
version: 3.7
is-latest-version: true
---

# Use Utility Classes in MUnit Tests

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

Use custom Java utility classes located in `src/test/java` in your MUnit tests through DataWeave or
the Java Module. Export the class package in your `mule-artifact.json` file to make it available
during test execution.

```json
{
  "minMuleVersion": "4.x.x",
  "classLoaderModelLoaderDescriptor": {
    "id": "mule",
    "attributes": {
      "exportedPackages": ["com.example.test"]
    }
  }
}
```

For example, assume that you want to use in an MUnit test a `MyUtilClass.java` class located in
`src/test/java/com/example/`:

MyUtilClass

```java
package com.example.test;

public class Helper {

  public static long getCurrentMillis() {
    return System.currentTimeMillis();
  }

}
```

## Invoke Your Java Class Using DataWeave

To invoke static methods using DataWeave you must add the `java!` prefix to the package name of the
class:

Use a class in DataWeave

```xml
<munit:test name="usingJavaInDW">
    <munit:behavior>
        <set-variable variableName="number" value="#[java!com::example::test::Helper::currentMillis()]" />
    </munit:behavior>
    <munit:execution>
        <flow-ref name="myFlow"/>
    </munit:execution>
</munit:test>
```

## Invoke Your Java Class Using Java Module

To invoke a custom Java class using Java Module:

1.  Ensure that Java Module is in your project:

    Java Module dependency

    ```xml
    <dependency>
        <groupId>org.mule.module</groupId>
        <artifactId>mule-java-module</artifactId>
        <version>${javaModule.version}</version>
        <classifier>mule-plugin</classifier>
        <scope>test</scope>
    </dependency>
    ```

2.  Use any of the Java Module’s operations.  
    For this example, invoke a static method of a class:

    Use a class with the Java Module

    ```xml
    <munit:test name="usingJavaInDW">
        <munit:behavior>
            <set-variable variableName="number" value="#[java!com::example::test::Helper::currentMillis()]" />
        </munit:behavior>
        <munit:execution>
            <flow-ref name="myFlow"/>
        </munit:execution>
    </munit:test>
    ```

<!-- document id=20f0238dbb7390a4b923710200e2da8c64f027b837e759d89e2e27160c8545af url=/mulesoft/current/en-us/munit/2.3/coverage-studio-concept.md -->

---
product: MUnit
version: 2.3
---

# Using Coverage in Studio

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

You can run a coverage report from Anypoint Studio.

The following configurations apply only when you execute your MUnit tests in Studio. They do not
apply when running tests from Maven in a CI/CD environment.  
To run coverage reports from Maven see [Maven Configuration for Coverage](https://docs.mulesoft.com/munit/2.3/coverage-maven-concept).

## Enable Coverage Reports in Anypoint Studio

You can see which flows, and which percentage of event processors in those flows the test covers by
clicking on the Coverage button:

![MUnit Coverage tab highlighted in the MUnit section](/mulesoft/current/en-us/munit/2.3/_images/using-munit-coverage-in-anypoint-studio.png)

The Overall Coverage value represents the percentage of the Mule application event processors that
the MUnit test executes.

You can click **Generate Report** to get the report that details the flows and event processors in
the Mule configuration files that are included in the MUnit test.

![Files included in the report highlighted](/mulesoft/current/en-us/munit/2.3/_images/munit-coverage-report-in-anypoint-studio.png)

<table><colgroup><col> <col></colgroup><thead><tr><th>Column</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><strong>Resource</strong></p></div></div></td><td><div><div><p>Name of the Mule configuration file</p></div></div></td></tr><tr><td><div><div><p><strong>Containers</strong></p></div></div></td><td><div><div><p>Number of flows inside the Mule configuration file</p></div></div></td></tr><tr><td><div><div><p><strong>Weight</strong></p></div></div></td><td><div><div><p>Percentage of your application in a configuration file<br>A percentage of the overall number of event processors in the documentation and the number of event processors in the Mule configuration file</p></div></div></td></tr><tr><td><div><div><p><strong>Coverage</strong></p></div></div></td><td><div><div><p>Percentage of event processors in the Mule configuration file that the MUnit test executes</p></div></div></td></tr></tbody></table>

Additionally, you can click on each **Resource** to get a more specific and granular report of the
Event Processors executed in that resource:

![MUnit Coverage Report with the Granular report highlighted](/mulesoft/current/en-us/munit/2.3/_images/munit-granular-coverage-report-in-anypoint-studio.png)

<table><colgroup><col> <col></colgroup><thead><tr><th>Column</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><strong>Name</strong></p></div></div></td><td><div><div><p>Name of the container</p></div></div></td></tr><tr><td><div><div><p><strong>Type</strong></p></div></div></td><td><div><div><p>Type of the container</p></div></div></td></tr><tr><td><div><div><p><strong>Covered Processors</strong></p></div></div></td><td><div><div><p>Processors inside the container that are executed during the MUnit test</p></div></div></td></tr><tr><td><div><div><p><strong>Processors</strong></p></div></div></td><td><div><div><p>Total amount of processors inside the container</p></div></div></td></tr><tr><td><div><div><p><strong>Coverage</strong></p></div></div></td><td><div><div><p>Percentage of the event processors inside the container executed in the MUnit test</p></div></div></td></tr></tbody></table>

## Disable Coverage Reports

If you choose so, you can disable the coverage calculation from your project run configuration so
you test your flow without a coverage report.

Right-click **Package Explorer** and choose **Run As** > **Run Configurations**. Select your MUnit
run configuration file to access your suite configuration, and deselect the **Run coverage** option
in your coverage settings.

![MUnit run and Run coverage highlighted](/mulesoft/current/en-us/munit/2.3/_images/disable-munit-coverage-in-anypoint-studio.png)

## Exclude XML Files from MUnit Coverage Report

You can exclude one or more XML files from an MUnit Coverage report when testing your application.
For example, you can exclude a third-party XML file that does not comply with your quality standards
to improve your final report score.

1.  Go to the flow to change.

2.  Click **Run** > **Run Configuration**.

3.  Click the name of your project.

4.  In the **Ignored files** section, click **Add**.

    ![Add Ignored File window highlighted in the Test tab](/mulesoft/current/en-us/munit/2.3/_images/add-ignored-files.png)

5.  Type the name of the XML file to exclude from the Coverage report and click **OK**.

6.  Click **Apply** and **Run**.

## See Also

- [Coverage](https://docs.mulesoft.com/munit/2.3/munit-coverage-report)

- [Maven Configuration for Coverage](https://docs.mulesoft.com/munit/2.3/coverage-maven-concept)

<!-- document id=ca57654f2ebd897ef2789a0153f15b0b101377a73fd7096fbc23b175c64c7316 url=/mulesoft/current/en-us/munit/3.6/coverage-studio-concept.md -->

---
product: MUnit
version: 3.6
---

# Using Coverage in Studio

> 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

You can run a coverage report from Anypoint Studio.

The following configurations apply only when you execute your MUnit tests in Studio. They do not
apply when running tests from Maven in a CI/CD environment.  
To run coverage reports from Maven see [Maven Configuration for Coverage](https://docs.mulesoft.com/munit/3.6/coverage-maven-concept).

## Enable Coverage Reports in Anypoint Studio

You can see which flows, and which percentage of event processors in those flows the test covers by
clicking on the Coverage button:

![MUnit Coverage tab highlighted in the MUnit section](/mulesoft/current/en-us/munit/3.6/_images/using-munit-coverage-in-anypoint-studio.png)

The Overall Coverage value represents the percentage of the Mule application event processors that
the MUnit test executes.

You can click **Generate Report** to get the report that details the flows and event processors in
the Mule configuration files that are included in the MUnit test.

![Files included in the report highlighted](/mulesoft/current/en-us/munit/3.6/_images/munit-coverage-report-in-anypoint-studio.png)

<table><colgroup><col> <col></colgroup><thead><tr><th>Column</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><strong>Resource</strong></p></div></div></td><td><div><div><p>Name of the Mule configuration file</p></div></div></td></tr><tr><td><div><div><p><strong>Containers</strong></p></div></div></td><td><div><div><p>Number of flows inside the Mule configuration file</p></div></div></td></tr><tr><td><div><div><p><strong>Weight</strong></p></div></div></td><td><div><div><p>Percentage of your application in a configuration file<br>A percentage of the overall number of event processors in the documentation and the number of event processors in the Mule configuration file</p></div></div></td></tr><tr><td><div><div><p><strong>Coverage</strong></p></div></div></td><td><div><div><p>Percentage of event processors in the Mule configuration file that the MUnit test executes</p></div></div></td></tr></tbody></table>

Additionally, you can click on each **Resource** to get a more specific and granular report of the
Event Processors executed in that resource:

![MUnit Coverage Report with the Granular report highlighted](/mulesoft/current/en-us/munit/3.6/_images/munit-granular-coverage-report-in-anypoint-studio.png)

<table><colgroup><col> <col></colgroup><thead><tr><th>Column</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><strong>Name</strong></p></div></div></td><td><div><div><p>Name of the container</p></div></div></td></tr><tr><td><div><div><p><strong>Type</strong></p></div></div></td><td><div><div><p>Type of the container</p></div></div></td></tr><tr><td><div><div><p><strong>Covered Processors</strong></p></div></div></td><td><div><div><p>Processors inside the container that are executed during the MUnit test</p></div></div></td></tr><tr><td><div><div><p><strong>Processors</strong></p></div></div></td><td><div><div><p>Total amount of processors inside the container</p></div></div></td></tr><tr><td><div><div><p><strong>Coverage</strong></p></div></div></td><td><div><div><p>Percentage of the event processors inside the container executed in the MUnit test</p></div></div></td></tr></tbody></table>

## Disable Coverage Reports

If you choose so, you can disable the coverage calculation from your project run configuration so
you test your flow without a coverage report.

Right-click **Package Explorer** and choose **Run As** > **Run Configurations**. Select your MUnit
run configuration file to access your suite configuration, and deselect the **Run coverage** option
in your coverage settings.

![MUnit run and Run coverage highlighted](/mulesoft/current/en-us/munit/3.6/_images/disable-munit-coverage-in-anypoint-studio.png)

## Exclude XML Files from MUnit Coverage Report

You can exclude one or more XML files from an MUnit Coverage report when testing your application.
For example, you can exclude a third-party XML file that does not comply with your quality standards
to improve your final report score.

1.  Go to the flow to change.

2.  Click **Run** > **Run Configuration**.

3.  Click the name of your project.

4.  In the **Ignored files** section, click **Add**.

    ![Add Ignored File window highlighted in the Test tab](/mulesoft/current/en-us/munit/3.6/_images/add-ignored-files.png)

5.  Type the name of the XML file to exclude from the Coverage report and click **OK**.

6.  Click **Apply** and **Run**.

## See Also

- [Coverage](https://docs.mulesoft.com/munit/3.6/munit-coverage-report)

- [Maven Configuration for Coverage](https://docs.mulesoft.com/munit/3.6/coverage-maven-concept)

<!-- document id=d94144bf7cb1f6b7796e0797e4bae0188ea21f1c9e89f1c7dacaf2f260e77e2a url=/mulesoft/current/en-us/munit/2.3/utility-classes-cookbook.md -->

---
product: MUnit
version: 2.3
---

# Using Utility Classes From a Test

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

When developing test cases, you might want to use custom Java classes located in `src/test/java`.
You can use Java classes through DataWeave or through Java Module.

When using custom classes, the package of the class must be exported in the `mule-artifact.json`
file:

```json
{
  "minMuleVersion": "4.x.x",
  "classLoaderModelLoaderDescriptor": {
    "id": "mule",
    "attributes": {
      "exportedPackages": ["com.example.test"]
    }
  }
}
```

For example, assume that you want to use in an MUnit test a `MyUtilClass.java` class located in
`src/test/java/com/example/`:

MyUtilClass

```java
package com.example.test;

public class Helper {

  public static long getCurrentMillis() {
    return System.currentTimeMillis();
  }

}
```

## Invoke Your Java Class Using DataWeave

To invoke static methods using DataWeave you must add the `java!` prefix to the package name of the
class:

Use a class in DataWeave

```xml
<munit:test name="usingJavaInDW">
    <munit:behavior>
        <set-variable variableName="number" value="#[java!com::example::test::Helper::currentMillis()]" />
    </munit:behavior>
    <munit:execution>
        <flow-ref name="myFlow"/>
    </munit:execution>
</munit:test>
```

## Invoke Your Java Class Using Java Module

To invoke a custom Java class using Java Module:

1.  Ensure that Java Module is in your project:

    Java Module dependency

    ```xml
    <dependency>
        <groupId>org.mule.module</groupId>
        <artifactId>mule-java-module</artifactId>
        <version>${javaModule.version}</version>
        <classifier>mule-plugin</classifier>
        <scope>test</scope>
    </dependency>
    ```

2.  Use any of the Java Module’s operations.  
    For this example, invoke a static method of a class:

    Use a class with the Java Module

    ```xml
    <munit:test name="usingJavaInDW">
        <munit:behavior>
            <set-variable variableName="number" value="#[java!com::example::test::Helper::currentMillis()]" />
        </munit:behavior>
        <munit:execution>
            <flow-ref name="myFlow"/>
        </munit:execution>
    </munit:test>
    ```

<!-- document id=d66ba6178f4482e7a5454f8d6c2ffbd7d9fb3476dd9b55c5967bf989cb8a77c1 url=/mulesoft/current/en-us/munit/3.6/utility-classes-cookbook.md -->

---
product: MUnit
version: 3.6
---

# Using Utility Classes From a Test

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

When developing test cases, you might want to use custom Java classes located in `src/test/java`.
You can use Java classes through DataWeave or through Java Module.

When using custom classes, the package of the class must be exported in the `mule-artifact.json`
file:

```json
{
  "minMuleVersion": "4.x.x",
  "classLoaderModelLoaderDescriptor": {
    "id": "mule",
    "attributes": {
      "exportedPackages": ["com.example.test"]
    }
  }
}
```

For example, assume that you want to use in an MUnit test a `MyUtilClass.java` class located in
`src/test/java/com/example/`:

MyUtilClass

```java
package com.example.test;

public class Helper {

  public static long getCurrentMillis() {
    return System.currentTimeMillis();
  }

}
```

## Invoke Your Java Class Using DataWeave

To invoke static methods using DataWeave you must add the `java!` prefix to the package name of the
class:

Use a class in DataWeave

```xml
<munit:test name="usingJavaInDW">
    <munit:behavior>
        <set-variable variableName="number" value="#[java!com::example::test::Helper::currentMillis()]" />
    </munit:behavior>
    <munit:execution>
        <flow-ref name="myFlow"/>
    </munit:execution>
</munit:test>
```

## Invoke Your Java Class Using Java Module

To invoke a custom Java class using Java Module:

1.  Ensure that Java Module is in your project:

    Java Module dependency

    ```xml
    <dependency>
        <groupId>org.mule.module</groupId>
        <artifactId>mule-java-module</artifactId>
        <version>${javaModule.version}</version>
        <classifier>mule-plugin</classifier>
        <scope>test</scope>
    </dependency>
    ```

2.  Use any of the Java Module’s operations.  
    For this example, invoke a static method of a class:

    Use a class with the Java Module

    ```xml
    <munit:test name="usingJavaInDW">
        <munit:behavior>
            <set-variable variableName="number" value="#[java!com::example::test::Helper::currentMillis()]" />
        </munit:behavior>
        <munit:execution>
            <flow-ref name="myFlow"/>
        </munit:execution>
    </munit:test>
    ```

<!-- document id=aa61d3fd8005b1b7170e4f39f8f21d2710811f23feffd90b411704f6b2b26c61 url=/mulesoft/current/en-us/munit/2.3/verify-event-processor.md -->

---
product: MUnit
version: 2.3
keywords: munit, testing, unit testing
---

# Verify Event Processor

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

The Verify Event processor allows you to verify if a processor was called.

For example, you can validate if a specific processor has been called with a particular set of
attributes a specific number of times.

When defining a verification, you are telling MUnit to fail a test if the verification is not
successful.

You can define verifications over any processor, even if you haven’t created a mock for it.

```xml
<munit-tools:verify-call processor="http:request" atLeast="1">
   <munit-tools:with-attributes>
       <munit-tools:with-attribute attributeName="method" whereValue="#['GET']" />
   </munit-tools:with-attributes>
</munit-tools:verify-call>
```

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>eventProcessor</code></p></td><td><p>Describes which event processor you want to mock. The description takes the form <code>{name-space}:{event-processor-name}</code>. It supports regular expressions.</p></td></tr><tr><td><p><code>times</code></p></td><td><p><strong>(Default = 1.)</strong> Defines the verification as successful if the event processor was called <em>N</em> and only <em>N</em> number of times.</p></td></tr><tr><td><p><code>atLeast</code></p></td><td><p>Defines the verification as successful if the event processor was called a minimum of <em>N</em> number of times.</p></td></tr><tr><td><p><code>atMost</code></p></td><td><p>Defines the verification as successful if the event processor was called maximum of <em>N</em> number of times.</p></td></tr></tbody></table>

The attributes `times`, `atLeast`, `atMost`, are mutually exclusive.

The `eventProcessor` attribute accepts regular expressions. For example, you can create the same
verification as `.*:request` to verify for an event processor named request, disregarding which
namespace the event processor belongs to. The regular expression language is the same as Java.

## See Also

- [Assert That Event Processor](https://docs.mulesoft.com/munit/2.3/assertion-event-processor)

- [Fail Event Processor](https://docs.mulesoft.com/munit/2.3/fail-event-processor)

- [Run Custom Event Processor](https://docs.mulesoft.com/munit/2.3/run-custom-event-processor)

- [Set Event Processor](https://docs.mulesoft.com/munit/2.3/set-event-processor)

- [Mock When Event Processor](https://docs.mulesoft.com/munit/2.3/mock-event-processor)

<!-- document id=16aaa7d9662e9de786e4577f063a082967297a7aec2dac166d73e704ad30bbbb url=/mulesoft/current/en-us/munit/3.6/verify-event-processor.md -->

---
product: MUnit
version: 3.6
keywords: munit, testing, unit testing
---

# Verify Event Processor

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

![logo acb active](/mulesoft/current/en-us/_/img/icons/anypoint-code-builder.svg "Anypoint Code Builder")Anypoint Code
Builder

![logo studio active](/mulesoft/current/en-us/_/img/icons/studio.svg "Anypoint Studio")Anypoint Studio

The Verify Event processor allows you to verify if a processor was called.

For example, you can validate if a specific processor has been called with a particular set of
attributes a specific number of times.

When defining a verification, you are telling MUnit to fail a test if the verification is not
successful.

You can define verifications over any processor, even if you haven’t created a mock for it.

```xml
<munit-tools:verify-call processor="http:request" atLeast="1">
   <munit-tools:with-attributes>
       <munit-tools:with-attribute attributeName="method" whereValue="#['GET']" />
   </munit-tools:with-attributes>
</munit-tools:verify-call>
```

<table><colgroup><col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>eventProcessor</code></p></td><td><p>Describes which event processor you want to mock. The description takes the form <code>{name-space}:{event-processor-name}</code>. It supports regular expressions.</p></td></tr><tr><td><p><code>times</code></p></td><td><p><strong>(Default = 1.)</strong> Defines the verification as successful if the event processor was called <em>N</em> and only <em>N</em> number of times.</p></td></tr><tr><td><p><code>atLeast</code></p></td><td><p>Defines the verification as successful if the event processor was called a minimum of <em>N</em> number of times.</p></td></tr><tr><td><p><code>atMost</code></p></td><td><p>Defines the verification as successful if the event processor was called maximum of <em>N</em> number of times.</p></td></tr></tbody></table>

The attributes `times`, `atLeast`, `atMost`, are mutually exclusive.

The `eventProcessor` attribute accepts regular expressions. For example, you can create the same
verification as `.*:request` to verify for an event processor named request, disregarding which
namespace the event processor belongs to. The regular expression language is the same as Java.

## See Also

- [Assert That Event Processor](https://docs.mulesoft.com/munit/3.6/assertion-event-processor)

- [Fail Event Processor](https://docs.mulesoft.com/munit/3.6/fail-event-processor)

- [Run Custom Event Processor](https://docs.mulesoft.com/munit/3.6/run-custom-event-processor)

- [Set Event Processor](https://docs.mulesoft.com/munit/3.6/set-event-processor)

- [Mock When Event Processor](https://docs.mulesoft.com/munit/3.6/mock-event-processor)