Page History

...

Where someName can be any string to uniquely identify the endpoint

...

Simple Example

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

...

You typically always call the assertIsSatisfied() method to test that the expectations were met after running a test.

Setting expectations

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

...

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=activemq/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.

Also note we instantiate a bean called myBean, here is the source of the MyAssertions bean.

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

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 and then invoke the assertEndpointsValid() method on it to verify that the mock endpoints have their assertions met. You could if you want 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.

Here is the actual JUnit test case we use.