In this chapter, we will cover:
- Testing routes defined in Java
- Using mock endpoints to verify routing logic
- Replying from mock endpoints
- Testing routes defined in Spring
- Testing routes defined in OSGi Blueprint
- Auto-mocking of endpoints
- Validating route behavior under heavy load
- Unit testing processors and Bean Bindings
- Testing routes with fixed endpoints using AOP
- Testing routes with fixed endpoints using conditional events
System integrations are traditionally a very difficult thing to test. Most commercial products, as well as home-cooked integrations, have no built-in support for automated testing. This usually results in verifying integration behavior through a manual approach involving triggering events/messages/requests from one window, and watching the end results in the affected systems. This approach has the following drawbacks:
- It is extremely time consuming, and inevitably leads to poor test coverage
- It is very difficult to test error conditions such as a system outage at just the wrong part of your integration flow
- It is complicated to verify the performance of integration code in isolation, as well as performing similar non-functional tests such as saturation testing
- It leaves no artifacts that can be used to detect regressions
Another fundamental problem with testing integrations using live backend systems is that it relies on the availability of those systems. This leaves your development workflow highly exposed to environment instability.
In most companies, the systems being integrated during development are often the test systems of other development teams. This means that they are likely to regularly be unavailable due to maintenance or code upgrades. The higher the number of systems being integrated, the greater the likelihood of any one of them is unavailable and prevents you from testing. This all-too-common scenario leaves teams scrambling for windows of opportunity when all their backends are up as the project deadline approaches.
Wouldn't it be nice if you could merely treat other systems as interfaces and test against those, rather than worrying about the physical implementations?
Camel comes with a built-in test kit that allows you to consider an integration to be just another set of code, in which backends are merely components that can be switched out for test versions.
This chapter covers the core elements of Camel that allow you to test your integrations, as well as providing some tips and techniques that should be applied given a set of circumstances.
If you have been looking at the example code from this book, you will have seen that the majority of the code is driven out of unit tests, and may have worked out which methods do what. This chapter and supporting samples focus exclusively on the JUnit framework, due to its overwhelming popularity among Java developers, being the de facto standard for unit testing. We will drill into the details of what is going on within Camel's support for JUnit so that you can then take that knowledge, and apply it to your testing framework of choice, regardless of whether Camel has explicit support for it or not.
The code for this chapter is contained within the camel-cookbook-testing module of the examples.