Free MuleSoft CONNECT Keynote & Expo Pass Available!

Register now+
Nav
You are viewing an older version of this section. Click here to navigate to the latest version.

About MUnit Test

The 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:

Scope Description

Behavior

The behavior scope is meant to set all the preconditions before executing the test logic.
Mocks and Spies should go in this section.

Execution

The execution scope is meant to have the testing logic which will be wait for all processes to finish before executing the next scope.

Validation

The validation scope is meant to have all the validations regarding the result of the execution scope.
Assertions and Verifications should go here.

All these scopes are optional.


         
      
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<munit:test name="exampleTest" description="Test to verify scenario 1">>

     <munit:behavior>
         <munit-tools:mock-when.../>
     </munit:behavior>

     <munit:execution>
         <flow-ref name="exampleFlow"/>
     </munit:execution>

     <munit:validation>
         <munit-tools:assert-that ...>
     </munit:validation>
 </munit:test>
munit-test
Figure 1. A Studio representation of the MUnit Test

About MUnit Test Description Attribute

In MUnit, it’s mandatory that you write a description in 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.

About MUnit Test Ignore Attribute

There may be scenarios where you need to shut down a test. Whether this be because the test is failing or because it has nasty side effects.
The point is you shouldn’t have to comment out the code.

In this case, MUnit allows you to ignore a specific test.

You can ignore any of your tests by adding the ignore boolean to the test definition.


         
      
1
2
3
4
<munit:test name="my-flow-Test"
      ignore="true"
      description="Test to verify scenario 1">
</munit:test>
Valid values for ignore are true and false. If the attribute is not present, the default is false.
ignore-test
Figure 2. In Anypoint Studio, you can check the Ignore Test option.

About MUnit Test Tag Attribute

MUnit also allows you to tag your tests, so you can choose to run tests under a specific tag. For example:


         
      
1
2
3
4
5
6
7
<munit:test
  name="exampleTest"
  description="A test that works as an example"
  ignore="true"
  tags="integration,http" ></munit:test>
test-tags
Figure 3. In Anypoint Studio, you can define tags in the proper field.

About MUnit Test Expected Error and Exception Attributes

Sometimes, the only thing you want to validate is that the flow or sub-flow you are testing fails and throws a specific error, which depends on the business logic being tested. In these cases, MUnit provides a simple way to validate the scenario.
You can add the attribute expectedErrorType and expectException, as shown below:


         
      
1
2
3
4
5
6
<munit:test name="MUnit-test-suite"
  description="A test that works as an example"
  expectedErrorType="RETRY_EXHAUSTED"
  expectedException="java.lang.RuntimeException">
  ...
</munit:test>
munit test concept e7280
Figure 4. A visual representation on Anypoint Studio
  • The attribute expectedErrorType expects an error ID that needs to be 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 exists in your application, the test does not run.

    
                   
                
    1
    2
    3
    4
    5
    
    <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 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 does 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 (canonical form).

    When you provide a literal value, it should take the form of the canonical class name of the exception that is expected. In these cases, Mule always throws a MuleMessagingException. MUnit validates the provided classname if the underlying cause of the MuleMessagingException thrown is of the exact same type.

    
                   
                
    1
    2
    3
    4
    5
    
    <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.