THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Instead of instantiating the CamelContext and routes programmatically, these classes rely on a Spring context to wire the needed components together. If your test extends one of these classes, you must provide the Spring context by implementing the following method.
...
You are responsible for the instantiation of the Spring context in the method implementation. All of the features available in the non-Spring aware counterparts from Camel Test are available in your test.
...
Here is a simple unit test using JUnit 3.x support from Spring Test using XML Config.Wiki Markup @DirtiesContext on the test methods to force Spring Testing to automatically reload the CamelContext after each test method - this ensures that the tests don't clash with each other, e.g., one test method sending to an endpoint that is then reused in another test method.
Also notice the use of @ContextConfiguration to indicate that by default we should look for the file FilterTest-context.xml on the classpath to configure the test case. The test context looks like:Wiki Markup FilterTest-context.xml from the classpath in the same package structure as the FilterTest class and initialize it along with any Camel routes we define inside it, then inject the CamelContext instance into our test case.
For instance, like this maven folder layout:
...
Plain Spring Test Using JUnit 4.x With Java Config Example
You can completely avoid using an XML configuration file by using Spring Java Config. Here is a unit test using JUnit 4.x support from Spring Test using Java Config.Wiki Markup ContextConfig class does all of the configuration; so your entire test case is contained in a single Java class. We currently have to reference by class name this class in the @ContextConfiguration which is a bit ugly. Please vote for SJC-238 to address this and make Spring Test work more cleanly with Spring JavaConfig.
...
You can avoid extending Spring classes by using the SpringJUnit4ClassRunner provided by Spring Test. This custom JUnit runner means you are free to choose your own class hierarchy while retaining all the capabilities of Spring Test.
...
This is for Spring 4.0.x. If you use Spring 4.1 or newer, then see the next section.
...
Plain Spring Test Using JUnit 4.1.x Runner With XML Config
You can avoid extending Spring classes by using the SpringJUnit4ClassRunner provided by Spring Test. This custom JUnit runner means you are free to choose your own class hierarchy while retaining all the capabilities of Spring Test.
...
...
From Spring 4.1, you need to use the @BootstrapWith annotation to configure it to use Camel testing, as shown below.
...
...
Camel Enhanced Spring Test
...
Annotation Class | Applies To | Description | Default Behavioir If Not Present | Default Behavior If Present |
|---|---|---|---|---|
|
| Indicates if JMX should be globally disabled in the CamelContexts that are bootstrapped during the test through the use of Spring Test loaded application contexts. | JMX is disabled | JMX is disabled |
|
| Indicates if certain route builder classes should be excluded from discovery. Initializes a | Not enabled and no routes are excluded | No routes are excluded |
|
| Deprecated. Indicates if the CamelContexts that are bootstrapped during the test through the use of Spring Test loaded application contexts should use lazy loading of type converters. | Type converters are not lazy loaded | Type converters are not lazy loaded |
|
| Triggers the auto-mocking of endpoints whose URIs match the provided filter. The default filter is | Not enabled | All endpoints are sniffed and recorded in a mock endpoint. |
|
| Triggers the auto-mocking of endpoints whose URIs match the provided filter. The default filter is | Not enabled | All endpoints are sniffed and recorded in a mock endpoint. The original endpoint is not invoked. |
|
| Indicates that the annotated method returns an | N/A | The returned |
|
| Indicates to set the shutdown timeout of all CamelContexts instantiated through the use of Spring Test loaded application contexts. If no annotation is used, the timeout is automatically reduced to 10 seconds by the test framework. | 10 seconds | 10 seconds |
|
| Indicates the use of The test author is responsible for injecting the Camel contexts into the test and executing | CamelContexts do not automatically start. | CamelContexts do not automatically start. |
|
| Camel 2.16:Indicates that the annotated method returns a | Override properties |
The following example illustrates the use of the @MockEndpoints annotation in order to setup mock endpoints as interceptors on all endpoints using the Camel Log component and the @DisableJmx annotation to enable JMX which is disabled during tests by default.
...
Adding More Mock Expectations
If you wish to programmatically add any new assertions to your test you can easily do so with the following. Notice how we use @EndpointInject to inject a Camel endpoint into our code then the Mock API to add an expectation on a specific message.
...
...
Further Processing the Received Messages
...
So you can then process the received message exchanges if you like...
...
...
Sending and Receiving Messages
...
To send or receive messages you should use the Bean Integration mechanism. For example to send messages inject a ProducerTemplate using the @EndpointInject annotation then call the various send methods on this object to send a message to an endpoint. To consume messages use the @MessageDriven annotation on a method to have the method invoked when a message is received.
...
See Also
- A real example test case using Mock and Spring along with its Spring XML
- Bean Integration
- Mock endpoint
- Test endpoint