Testing is a crucial activity in any piece of software development or integration. Typically, Camel users would use various different technologies wired together in a variety of EIPs with different endpoints, languages, bean integration, and dependency injection, so it’s very easy for things to go wrong!. Testing is the crucial weapon to ensure that things work as you would expect.

Camel is a Java library, so you can easily wire up tests in JUnit. However, the Camel project has tried to make the testing of Camel as easy and powerful as possible, so we have introduced the following features.

Testing modules

The following modules are supported:

Component Description


JUnit 4 (deprecated): Is a standalone Java library letting you easily create Camel test cases using a single Java class for all your configuration and routing without.


JUnit 5: Is a standalone Java library letting you easily create Camel test cases using a single Java class for all your configuration and routing without.


JUnit 5: Used for testing Camel in Camel Main mode


JUnit 4 (deprecated): Used for testing Camel with Spring / Spring Boot


JUnit 5: Used for testing Camel with Spring / Spring Boot


JUnit 4 (deprecated): Used for testing Camel on CDI


JUnit 5: Used for testing Camel on CDI


Camel Test Infra: Camel Test Infra is a set of modules that leverage Test Containers and abstract the provisioning and execution of test infrastructure. It is the successor of the camel-testcontainers components.

If you are using Camel Quarkus then you can find information in its documentation how to do testing with Quarkus and Camel.

In all approaches the test classes look pretty much the same in that they all reuse the Camel binding and injection annotations.

For more details on the different testing modules, then see their respective documentation from the links in the table above.

Testing functionality

Camel provides a set of features that are common to use when writing unit or integration tests with Camel.

Testing endpoints

Camel provides a number of endpoints which can make testing easier.

Name Description


For testing routes and mediation rules using mocks and allowing assertions to be added to an endpoint.


For load & soak testing this endpoint provides a way to create huge numbers of messages for sending to components and asserting that they are consumed correctly.

DataSet Test

Used for automatic load a set of expected message from another endpoint which is then compared to the messages that arrives at this endpoint.

The main endpoint is the Mock endpoint which allows expectations to be added to different endpoints; you can then run your tests and assert that your expectations are met at the end.

Stubbing out physical transport technologies

If you wish to test out a route but want to avoid actually using real physical transport (for example to unit test a transformation route rather than performing a full integration test) then the following endpoints can be useful:

Name Description


Direct invocation of the consumer from the producer so that single threaded (non-SEDA) in VM invocation is performed which can be useful to mock out physical transports


Deliver messages asynchronously to consumers via a BlockingQueue which is good for testing asynchronous transports


Works like SEDA but does not validate the endpoint URI, which makes stubbing very easy.

Testing existing routes

Camel provides some features to aid during testing of existing routes where you cannot or will not use Mock etc. For example, you may have a production ready route which you want to test with some 3rd party API which sends messages into this route.

Name Description


Allows you to be notified when a certain condition has occurred. For example when the route has completed 5 messages. You can build complex expressions to match your criteria when to be notified.


Allows you to advice (enhance) an existing route using a RouteBuilder style. For example, you can send (or send and skip) message to a Mock endpoint for validating the message send by Camel is as expected.

Third Party Testing libraries

There are a number of third party testing libraries that Camel users have found useful.

Name Description

Citrus Integration Framework

Framework for automated integration tests supporting a wide range of message protocols and data formats

Citrus Yaks

YAKS is a framework to enable Cloud Native BDD testing on Kubernetes