## Name

Mock — provides a declarative framework for testing routes

## Overview

Mock endpoints provide a powerful declarative testing mechanism similar to jMock. It allows declarative expectations to be created on any Mock endpoint before a test begins. When the test is run, which typically fires messages to one or more endpoints, the expectations can be asserted in a test case to ensure the system worked as expected.

This allows you to test things like:

- The correct number of messages are received on each endpoint

- The correct payloads are received and in the right order

- Messages arrive on an endpoint in the right order

- Messages arrive on an endpoint in order according to some `Expression` that implements an order testing function

- Arriving messages match some kind of predicate (such as specific headers that have specific values) or message parts match some predicate (such as evaluation by an `XPath` or `XQuery` expression)

| Note
The Test endpoint is a mock endpoint that uses a second endpoint to provide the list of expected message bodies and automatically sets up the mock endpoint assertions.

| Important
Mock endpoints keep received Exchanges in memory indefinitely. When you add Mock endpoints to a route, each Exchange sent to those endpoints is stored in memory (for later validation) until an explicit reset or the JVM is restarted. Sending large messages or a high volume of messages may result in excessive memory use. If your goal is to test deployable routes inline, use `NotifyBuilder` or `AdviceWith` in your test, instead of adding Mock endpoints directly to routes. Alternatively, you can use the `retainFirst` and `retainLast` options together to limit the number of Exchanges that Mock endpoints retain in memory. See Limiting the number of Exchanges to keep.

## Dependencies

Maven users will need to add the dependency shown in Example 18, “Mock dependency” to their `pom.xml` to use this component.

Example 18. Mock dependency

    <dependency>
        <groupId>org.apache.camel</groupId>
        <artifactId>camel-test</artifactId>
        <version>x.x.x</version>
        <!-- use the same version as your Camel core version -->
    </dependency>

## URI format

Mock endpoints have the following URI format:

    mock:someName[?options]

`someName` can be any string that uniquely identifies the endpoint.

## Options

Table 49, “Mock options” describes the options for a mock endpoint.

Table 49. Mock options

Option | Default | Description
--- | --- | ---
`retainFirst` |  | Specifies the number of first Exchanges to retain in memory.
`retainLast` |  | Specifies the number of last Exchanges to retain in memory.
`reportGroup` | `null` | Specifies a size to use for a throughput logger for reporting.

## Limiting the number of Exchanges to keep

You can use the `retainFirst` and `retainLast` options together to instruct Mock endpoints to retain only the specified number of first and last Exchanges in memory. The following code snippet retains a copy of the first five and last five Exchanges that the Mock endpoint receives:

    MockEndpoint mock = getMockEndpoint("mock:data");
    mock.setRetainFirst(5);
    mock.setRetainLast(5);
    mock.expectedMessageCount(2000);
       ...
    mock.assertIsSatisfied();

Some limitations are associated with using these options. The `getExchanges()` and `getReceivedExchanges()` methods on the `MockEndpoint` return only the retained copies of the Exchanges. So, for our example snippet, the returned list would contain only ten Exchanges—the first five and the last five.

The `retainFirst` and `retainLast` options also limit which expectation methods you can use. For example, the `expected` `XXX` methods that work on message bodies, headers, and so on, work only on retained messages. For our example snippet, `expected` `XXX` methods would test expectations only on the ten retained Exchanges.