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]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]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

OptionDefaultDescription
retainFirst Specifies the number of first Exchanges to retain in memory.
retainLast Specifies the number of last Exchanges to retain in memory.
reportGroupnullSpecifies 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 expectedXXX methods that work on message bodies, headers, and so on, work only on retained messages. For our example snippet, expectedXXX methods would test expectations only on the ten retained Exchanges.