Unit Testing Camel Routes with Spock


Apache Camel’s variety of components and message routing logic capabilities makes testing a requirement to ensure your routes are performing as expected. Since Camel routes are built within a context, it usually follows that to test those routes an integration test is required to verify the routing logic.

But what if you don’t want a full fledged context just to have a test case to cover some simple routing logic? Do you really need to wire up a test database and provide all the other information an integration test requires just to test a conditional in your routing logic? Of course not, unit testing would be the obvious and logical choice.

To that end, I’ve chosen my favorite testing framework, Spock, to explore a simple way to unit test camel routing logic.

Camel Route Builder

Let’s say you have a simple route builder class that takes in a message object, performs a simple operation on that message and passes it along to an output route that spits it out to a pre-defined log.

Unit Test


Let’s take a look at what’s needed to unit test the “choice” logic in this camel route.

First, start with some basic Spock mocking and test setup. For this specific class, we see two services that are autowired and used in the route logic. Let’s mock those out as we don’t care to test those specific services functions, just that they were called at the appropriate times.

Next, we need to register this router within a minimal Camel context so that we can send messages through the routes. To do that we create a DefaultCamelContext and use some Camel testing methods to Mock the endpoints that we don’t want to actually process messages. For this use case, let’s imagine that the “log:out” endpoint is something that shouldn’t get invoked during unit testing. I recommend doing this in the setup method as Spock invokes that before each test case.

Test Cases

Ok, we’ve mocked the services and the integration endpoint, now let’s start the tests. First, register the mocked endpoint so you can assert your conditions. Second, register a producer template in the context so you can send messages through your routes. Finally, we can send a message through the route and use some Spock mock asserts to verify the message did not get sent to the test-output route.

Now to prove a message with the proper header can get through to the “log:out” endpoint and invoke the proper services…

And that’s it. We have used the Spock testing framework to unit test your Camel routing logic.


Since we are manually making the Camel context, we need to clean up after ourselves after every test. Calling .stop on the context in the cleanup method is enough cleanup for the purposes of these unit tests.

Code Readability

There are a lot optimizations that can be made to the Spock specification to reduce code duplication and increase overall readability of the tests.

Using non-static strings to define endpoints to be mocked can lead to headaches if the router is refactored later. I tend to define the Endpoint URIs as static final strings in a utility class so that I can use that reference in both the router class and any subsequent test classes.

Resolving mocked endpoints in the ‘given’ block of each test is also inefficient and adds more repeated code per test. I usually define the MockEndpoint objects for the entire Specification and resolve them in the ‘setup’ Spock method. If you decide to define these global endpoints, be sure to reset them in the ‘cleanup’ method or it could lead to assertions not being resolved properly during testing.


For a look at the project, feel free to look at the complete project on my Github or if you are just interested in the test cases, take a look at the complete Specification.

About the Author

Chris Tosspon profile.

Chris Tosspon

Sr. Consultant

Chris is a developer passionate about solving complex problems. With his knowledge of cryptography and advanced hardware attacks, he pursued the life of a hardware hacker before turning his attention on software development and engineering.

Chris builds applications using Spring, Java, Groovy, and has experience with most of the popular Java testing frameworks, e.g. Spock, TestNG, JUnit.

One thought on “Unit Testing Camel Routes with Spock

  1. Eden Fantasys says:

    I am trying to create integration test for a camel route. My route reads a message from kafka, transforms it and sends it to another kafka. During the integration test, I am able to create in memory kafka producer and consumer to publish message and consume it. However, during the execution of my end to end camel route, I don’t want to hit the actual end point and instead wants to return a response from my test. I thought I will use MockServerClient using

  2. rama krishna says:

    thanks for your article, try to write for other types of routes also

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Blog Posts
AWS Cloud HSM, Docker and NGINX
There is quite a bit of easily searchable content on the security benefits of leveraging a Hardware Security Module to manage cryptographic keys, so I will leave that to the scope of another article. The […]
Google Professional Machine Learning Engineer Exam 2021
Exam Description A Professional Machine Learning Engineer designs, builds, and productionizes ML models to solve business challenges using Google Cloud technologies and knowledge of proven ML models and techniques. The ML Engineer is proficient in all aspects […]
Designing Kubernetes Controllers
There has been some excellent online discussion lately around Kubernetes controllers, highlighted by an excellent Speakerdeck presentation assembled by Tim Hockin. What I’d like to do in this post is explore some of the implications […]
React Server Components
The React Team recently announced new work they are doing on React Server Components, a new way of rendering React components. The goal is to create smaller bundle sizes, speed up render time, and prevent […]