Test automation for Apache Camel projects

Question

Hello Camel community,

I’ve got some questions regarding test execution and automation. I am using Red Hat Fuse 7.7 (i.e. Camel 2.21.0 and Karaf 4.2.6 as OSGi base).

I’m interested in automated testing and therefore implemented some Unit-Tests based on CamelBlueprintTestSupport. But unfortunately, when having a bunch of tests (approx. 20), the performance of the test execution is very slow. Does anybody else have performance problems, too? Is it because of the complex process of loading PojoSR in the background?

I’ve also tried to set up integration tests with Pax-Exam. But as my projects are quite complex in general, it takes much time installing all needed features and dependent components. Is it only me who struggles with the framework? The performance is bad again and it seems to be nearly impossible to create a test set-up which allows using dependencies like camel-sql or Drools (kie) as they depend again on other artifacts like spring, etc.

What experience do you have with testing? What tools do you use to check if your integration generates the correct output for a given input?

I’ll be looking forward hearing your experience and getting in discussion. Regards

Answer 1

What you describe, has led to the testing pyramid.

Write loads of very fast unit-tests to test every special case you can think of - on method or class level.

But on integration test level every test takes some time to execute. Therefore you should narrow them down to the essential test cases that cannot be tested in lower test levels.

You call Camel Route tests "unit-tests", but since they need the whole application context or at least more than just a class, I would count them to a higher level in the pyramid (service-, component-tests, there are many names around). Therefore I already try to reduce them to the required minimum.

My strategies to keep Camel testing effort low are quite common:

• I put Java code into JavaBeans and call them from the routes. Like this, I can unit test the Java Beans thoroughly with plain JUnit and I don't need to test all these variations with route tests.
• I split my routes. Instead of one huge route with dozens of possible code execution paths, I create compact small routes with "1 to some" possible execution paths. This is the same principle as with huge vs. small methods. The number of possible paths are multiplied in huge methods or routes.
• I use Spring, not OSGi, but a Camel test class for Spring Framework can run all test methods with the same Spring Context (without restarting the context between tests). This reduces test execution time quite noticeable. But this depends on the route and test requirements (there is a reason Spring can restart "dirty contexts" between tests) and I don't know how Blueprint tests behave.