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
Android Development for iOS Developers
Android development has greatly improved since the early days. Maybe you tried it out when Android development was done in Eclipse, emulators were slow and buggy, and Java was the required language. Things have changed […]
Add a custom object to your Liquibase diff
Adding a custom object to your liquibase diff is a pretty simple two step process. Create an implementation of DatabaseObject Create an implementation of SnapshotGenerator In my case I wanted to add tracking of Stored […]
Keeping Secrets Out of Terraform State
There are many instances where you will want to create resources via Terraform with secrets that you just don’t want anyone to see. These could be IAM credentials, certificates, RDS DB credentials, etc. One problem […]
Validating Terraform Plans using Open Policy Agent
When developing infrastructure as code using terraform, it can be difficult to test and validate changes without executing the code against a real environment. The feedback loop between writing a line of code and understanding […]