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

Leave a Reply

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

Related Blog Posts
Using Conftest to Validate Configuration Files
Conftest is a utility within the Open Policy Agent ecosystem that helps simplify writing validation tests against configuration files. In a previous blog post, I wrote about using the Open Policy Agent utility directly to […]
SwiftGen with Image & Color Asset Catalogs
You might remember back in 2015 when iOS 9 was introduced, and we were finally given a way to manage all of our assets in one place with Asset Catalogs. A few years later, support […]
Tracking Original URL Through Authentication
If you read my other post about refreshing AWS tokens, then you probably have a use case for keeping track of the original requested resource while the user goes through authentication so you can route […]
Using Spring Beans in a Kafka Streams ExceptionHandler
There are many things to know before diving into Kafka Streams. If you haven’t already, check out these 5 things as a starting point. Bullet 2 mentions designing for exceptions. Ironically, this seems to be […]