--- schema_version: "1" id: 2b98c45686832ec22e4cf1687a243ec692730bf1906aa8345af7b2b232ee4bea title: Testing and Mocking Errors collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/munit/2.3/test-mock-errors-cookbook.md canonical_url: https://docs.mulesoft.com/munit/2.3/test-mock-errors-cookbook source_site: docs.mulesoft.com content_type: documentation content_hash: d56e919f287b0172e7dedc827bdd60d02f3161d11e6d41cd1ab606b1c41bddd5 description: MuleSoft Documentation Site release: "2.3" latest: false --- --- 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 ``` 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 ``` ## 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 ``` 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 ``` 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 ``` 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 ``` ## 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 ``` 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 ``` 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 ``` ## 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 ``` 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 ``` ## 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)