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:
The behavior scope is meant to set all the preconditions before executing the test logic.
The execution scope is meant to have the testing logic which will wait for all processes to finish before executing the next scope.
The validation scope is meant to have all the validations regarding the result of the execution scope.
All these scopes are optional.
<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>
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.
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.
<munit:test name="my-flow-Test" ignore="true" description="Test to verify scenario 1"> </munit:test>
Valid values for
MUnit also allows you to tag your tests, so you can choose to run tests under a specific tag. For example:
<munit:test name="exampleTest" description="A test that works as an example" ignore="true" tags="integration,http" > … </munit:test>
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:
<munit:test name="MUnit-test-suite" description="A test that works as an example" expectedErrorType="RETRY_EXHAUSTED" expectedException="java.lang.RuntimeException"> ... </munit:test>
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.
<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 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 (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
MuleMessagingExceptionthrown is of the exact same type.
<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.