Hello Henri! Did you already checked out the following links [1], [2]? With "adviceWith" you can manipulate your route in your test and "wire tap" the message to a mock endpoint which can check your expectations. You can also skip sending the message to the original endpoint (may be cause the system is not available in your development/test environment). "weaveById" is another powerful possibility to ...
[1] http://camel.apache.org/advicewith.html [2] http://camel.apache.org/mock.html Best, Christian On Sun, Nov 4, 2012 at 10:09 AM, Henri Tremblay <[email protected]>wrote: > Hi, > > I've started to play with Camel and loving it. However, I'm still having > problems with the testing. > > I want to do an integration test of a complete message processing. Here's > the flow, please focus on the solution, not on the fact that the > architecture is a nonsense, that part isn't really my fault (but I can use > any useful ideas) > > Here it goes: > > 1. Message received from JMS > 2. Stored in DB > 3. Read from DB with a consumer > 4. Sent to a direct route > 5. Status changed > 6. Sent to another system in REST > 7. The other system will change the status in DB and create new DB > entries > 8. Read from DB with another consumer the new DB entries > 9. Sent to the same direct route > 10. Sent them to the same system in REST > > My questions are > > - I want to check the message when entering in both direct route. How > calls like expectedMessageCount are working? Is it ordered? So I should > put > an expectedMessageCount(1) for the first call and another for the > second a > bit below in my test > - I want to be able to check the status changed at point 5 before it is > changed again at step 7. How can I do that? > - What's the ordering of things like > expectedMessageCount, expectedBodyReceived? When they are specified in a > row, they always apply to the same message? Is message(0) working the > same > way? > > If it can help understanding the questions, I'm an EasyMock dude. So I'm > trying to map the Camel expectation to their equivalent EasyMock behavior. > > Any help? > > Thanks, > Henri > --
