Page History

...

The Mock component provides a powerful declarative testing mechanism, which is similar to jMock in that it allows declarative expectations to be created on any Mock endpoint before a test begins. Then the test is ran run, which typically fires messages to one or more endpoints, and finally the expectations can be asserted in a test case to ensure the system worked as expected.

This allows you to test various things like:

• the The correct number of messages are received on each endpoint,
• that the The correct payloads are received, in the right order,
• that messages Messages arrive on an endpoint in order, using some Expression to create an order testing function,
• that messages Messages arrive match some kind of Predicate such as that specific headers have certain values, or that parts of the messages match some predicate, such as by evaluating an XPath or XQuery Expression.

Note that there is also the Test endpoint which is - a Mock endpoint, but which also uses a second endpoint to provide the list of expected message bodies and automatically sets up the Mock endpoint assertions. i.e. its In other words, it's a Mock endpoint which that automatically sets up its assertions from some sample messages in a File or database, for example.

URI format

mock:someName[?options]

Where someName can be any string to that uniquely identify identifies the endpoint.

You can append query options to the URI in the following format, ?option=value&option=value&...

Options

...

Here's a simple example of MockEndpoint Mock endpoint in use. First, the endpoint is resolved on the context. Then we set an expectation, and then, after the test has run, we assert that our expectations are have been met.

MockEndpoint resultEndpoint = context.resolveEndpoint("mock:foo", MockEndpoint.class);

resultEndpoint.expectedMessageCount(2);

// send some messages
...

// now lets assert that the mock:foo endpoint received 2 messages
resultEndpoint.assertIsSatisfied();

...

You can see from the javadoc of MockEndpoint the various helper methods you can use to set expectations. The main methods available are as follows:

...

Adding expectations to specific messages

In addition, you can use the message(int messageIndex) method to add assertions about a specific message that is received.

For example, to add expectations of the headers or body of the first message (using zero-based indexing like java.util.List), you can use this the following code:

resultEndpoint.message(0).header("foo").isEqualTo("bar");

There are some examples of the Mock endpoint in use in the camel-core processor tests.

A Spring Example

First, here's the spring.xml file

{snippet:id=example|lang=xml|url=camel/trunk/components/camel-spring/src/test/resources/org/apache/camel/spring/mock/spring.xml}

As you can see, it defines a simple routing rule which consumes messages from the local src/test/data directory. The noop flag just means not to delete or move the file after its been processed.

...

The bean is injected with a bunch of Mock endpoints using the @EndpointInject annotation, it then sets a bunch of expectations on startup (using Spring's InitializingBean interface and afterPropertiesSet() method) before the CamelContext starts up.

Then in our test case (which could be JUnit or TesNG) we lookup myBean in Spring (or have it injected into our test) and then invoke the assertEndpointsValid() method on it to verify that the mock endpoints have their assertions met. You could then inspect the message exchanges that were delivered to any of the endpoints using the getReceivedExchanges() method on the Mock endpoint and perform further assertions or debug logging.

...