Since http://camel.apache.org/spring-testing.html do not provide a full example on how to create camel-spring tests with annotation configuration, I decided to do it on my own. I was struggling with camel-spring tests multiple times and always forgot how to write those tests. Its basically gradle project about how to test your camel routes with spring application context.
- using spring xml test application context
- using annotation config. application context
The main difference is in what loader has been used. In 1-st case I used the common CamelTestContextBootstrapper as documented on camel site. In the 2-nd case I've created custom CustomTestContextBootstrapper which uses already implemented CamelSpringDelegatingTestContextLoader which supports parameter classes in @ContextConfiguration annotation.
Still, you can use loader parameter in @ContextConfiguration annotation with eather CamelSpringDelegatingTestContextLoader for annotation config support or CamelSpringTestContextLoader for xml locations support. But the main reason to use it is that you can create your AbstractRouteTest and use this annotation there and your extended test doesn't need to specify loader in @ContextConfiguration annotation all the time (if your tests are using different contexts).
Besides that first one supports only xml configurations and second one supports both, they are pretty much the same. The CamelSpringTestContextLoader supports also @LazyLoadTypeConverters, but this functionality is already deprecated. I would go with the second one. I've also noticed, that CamelSpringDelegatingTestContextLoader do not have it's own bootstrapper, so you need to create it (as I did) or just use loader parameter. Note, that @BootstrapWith is available in spring since version 4.1.
All as described here
This annotation(s) can actually save you from weaving your routes. Maybe it's self-explanatory, but I can explain:
If your endpoint is file://out?fileName=asdf mocked endpoint will looks like this mock://file:out. You can mock it with simple file:* regexp. Also, it doesn't matter if you use also the mock://... or just mock:..., the InterceptSendToMockEndpointStrategy used in loader will do the normalization for you. Mind, that this will create a proxy over this endpint and it will actually call the original one! If you don't want it to happen, use @MockEndpointsAndSkip
- weaving with
@UseAdviceWith