This is my own attempt to uncover the testing features of Apache Camel. Testing Camel routes has its significance for a quality outcome. As a Camel developer, Knowing Camel is very easy. Ah its all From and To’s. But today, I realized Camel as a framework stands out as a genius not just because of its implementation advantage. But for its features like ‘Testing’.
You can find many good materials about ‘Testing Camel’ in many sources like Camel in Action book, Apache Camel Developers Cookbook, Camel website, Unit tests of various camel components & examples. I have just summarized what I have observed from all them.
What a Integration developer should be concerned of ?
Yes obviously performance, because its a middleware. The answer is Testing. Test driven development is the trend now. Prepare your unit tests, then start your real implementation. Then further comes the Integration test connecting to the real endpoints. Better the Unit tests, better the quality of the Integration application.
What should be the testing strategy for Camel as a Integration product ?
The same unit tests and integration tests applies for Camel. Camel context is the engine of Apache Camel, Routes are the core parts of a camel context.
Before engine assembly, each part has to be tested well. So that after assembly the engine can perform well. This is it. Routes has to be tested well before you focus on building the Camel context, then later you can obviously carry on with the Integration tests with the real endpoints !
How units tests are done ?
Lets say you are going to Integrate 5 different applications using Camel. Each application is heterogeneous in terms of connectivity. JMS, Web services, File system, Database & AMQP. Using camel testing features, You can mock all these different endpoints for unit testing. Means, You can emulate these endpoints.
Ofcourse you can emulate these applications/endpoint using plain Java skills. But Camel provides some features which gives you more convenience for unit testing.
There is no point in Unit testing the Camel routes with the real endpoints, because the time you spend in configuring the real endpoints you can directly Implement the Camel context. Because Configuring real endpoints is the main beauty of Camel, Please don’t do it during unit testing.
Also in big projects, each applications will be managed by different teams. You cannot expect the endpoint details in the early days of your project.
Camel provides lot of In-Memory endpoints like Direct, Direct-VM, Seda, VM, Mock to do unit testing. Also Camel provides Camel test support for your Java, Spring & Blueprint based contexts.
This helps you to focus on ‘ What is in between the From & To endpoints ‘ like Transformation, Rules, Routing & Enrichment.
What will happen if you build the Camel context without Unit tests ?
Simple ! You will keep changing the Camel contexts and the flow of routes. Also if you have requirements for using MEP ( Message Exchange Patterns ) in Camel. Then Unit testing is a mandatory one. Because without unit tests, You may have to replace the ‘InOut’ with ‘InOnly’ & ‘InOut’ with ‘InOptionalyOut’. Then ultimately you will forget what was the actually business flow requirement.
Lets talk something technical.
1. Testing Camel routes is very similar to Wire Tapping ( Doesn’t mean using Wire Tap pattern ! ). You have a route -> From ‘A’ to ‘B’ . You can test it in two ways, either a) Go and see what is in ‘B’ directly or b) Forward the data from ‘B’ to ‘Test endpoint’ validate the data.
2. If this your testing scope, then make sure there is no consumers are looking for data from either ‘B’ or ‘Test endpoint’.
3. Here comes the ‘Mock’ endpoint. For the above scenario, either ‘B’ can be a Mock endpoint or ‘Test endpoint’ is can be a Mock endpoint. ( No one can consume from Mock )
4. Then further once you receive the data in Mock. Apply your test conditions and validate the data. (This article talks about using mock endpoint : http://bushorn.com/camel-unit-testing-using-mock-endpoint/)
5. For validating the data, Mock is very powerful. It provides various methods and assertions to validate your data(messages). Like, Validating message body, Order of messages, Count of messages etc.
1. Use direct endpoints. Direct endpoints are useful for synchronous communication. If you want to replace a web service endpoint, you can use direct.
2. Keep in mind, Direct cannot have more than 1 consumer. If you are going to route/forward the message to ‘Mock’ endpoint then make sure there is no other consumer in the subsequent routes.
1. Use property placeholders effectively, So that you don’t need to maintain mutiple camel contexts for testing and development purpose.
2. But if you have anyway hardcoded the real endpoints, using adviceWith It can replace your real endpoints with another endpoint. It can even replace your processors with some other processor.
3. Lets assume your ‘Atm Debit Card’ is your message. This is your route: From ‘Wallet’ to ‘ATM Machine’ to ‘Physical card Validator’ to ‘Bank network’ to ‘Visa/Master Card network’ to ‘ Show message: Your card is invalid ‘ . In testing world of Camel, If you use adviseWith(). You can say ” Replace ‘Physical card Validator’ to ‘Bank network’ to ‘Visa/Master Card network’ ” with ” My own test mock validator ” which will show the message ” You card is invalid “.
Because you cannot ask the real endpoints to perform for your testing activities. May be the bank you are integrating with may not even have a Testing environment.
I think, I reached my saturation in typing. Let me give few important links and tips:
1. The chapters about testing in ‘Camel in Action’ and ‘Apache Camel Developers Cookbook’ together comes to 70 pages. Hardly 20 pages of real words. Read it.
2. If not, Go to Camel source -> Components -> Test directories. Collectively you will find more than 500 test cases, You will crack it.
3. If not, Download the code/exercises from various sources like Blogs, Github. Grab the test cases.
4. If not, Download Fuse IDE: Create a Camel context -> Right click -> New -> Camel JUnit Test cases -> Select input and output endpoints -> Generate a ready made Camel Unit test case for you. You have apply your conditions and just right click and run it.
5. If you not familiar to unit test a large camel context ? Don’t mind, You can create multiple camel context files for every route and do unit testing. ( Am still exploring a better approach to do this, But my concise says ‘Its Okay’. Because it will give you a quality outcome. Starting with Camel and For Smaller project this is fine. )
6. Post your questions to forums like Camel nabble, JBoss Forums or Stackover flow.
Just to be funny, If nothing works out. Create another Camel context project and do the unit testing in the Camel context XML itself Because Camel can run standalone using ‘mvn camel:run plugin’
Hope it helps, I will keep updating this page whenever I get some time. Well, Lets complete this with a simple philosophy.
Change is permanent in life, Everything changes. Life is change, Something stagnant is death. Camel is a very interesting product, Many gets fed up because of what is not there in it. Many others get fed up for So much in camel, which one to use. The fact is, Camel is changing. What is there today, will not be there tomorrow. Camel-simple is interesting today, Tomorrow it may look complex. So it will takes its transformation. But make sure you ride in it atleast once a worthwhile. The experience of riding is different from watching someone riding it.