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
An Exploration in Rust: Musings From a Java/C++ Developer
Why Rust? It’s fast (runtime performance) It’s small (binary size) It’s safe (no memory leaks) It’s modern (build system, language features, etc) When Is It Worth It? Embedded systems (where it is implied that interpreted […]
Getting Started with CSS Container Queries
For as long as I’ve been working full-time on the front-end, I’ve heard about the promise of container queries and their potential to solve the majority of our responsive web design needs. And, for as […]
Simple improvements to making decisions in teams
Software development teams need to make a lot of decisions. Functional requirements, non-functional requirements, user experience, API contracts, tech stack, architecture, database schemas, cloud providers, deployment strategy, test strategy, security, and the list goes on. […]
JavaScript Bundle Optimization – Polyfills
If you are lucky enough to only support a small subset of browsers (for example, you are targeting a controlled set of users), feel free to move along. However, if your website is open to […]