camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Babak Vahdat <babak.vah...@swissonline.ch>
Subject Re: mock.expectedMessageCount(0) resulting in a false positive
Date Thu, 13 Dec 2012 16:31:41 GMT


Am 13.12.12 13:51 schrieb "camel.user2.ch" unter <camel.user.ch@gmail.com>:

>Hi Babak,
>
>Thanks a lot for your reply, it confirms what I suspected from looking
>through the source. I can see that when you setExpectedMessageCount(0),
>there is no countdown latch, resulting in the mock being asserted on
>pretty
>much straight away.

That's correct.

>
>I don't really like the MockEndpoint.setSleepForEmptyTest() idea as it's
>pretty much analogous to sticking an arbitrary Thread.sleep() into the
>code.

This is just a matter of personal taste.

>
>The NotifyBuilder example seems to work a lot nicer however, thanks a lot
>for your suggestion. I now have:
>
>       // wait for the message to pass through the route before running
>the
>assertions.
>        // JMS msgs are processed asynchronously creating a race condition
>for the test.
>        NotifyBuilder notify = new
>NotifyBuilder(context).whenDone(1).create();
>        notify.matches(500, TimeUnit.MILLISECONDS);
>
>        sftpMockEndpoint.assertIsSatisfied();
>
>And this is working as expected.
>
>I'm a little surprised that there is not much mention of this potential
>race
>condition when using the Camel testing framework - neither within the
>online
>documentation nor within the Camel in Action book. It seems to be a pretty
>big omission within what is otherwise an excellent and well documented
>framework.

Check the page 295 with an example where it says:

QUOTE_BEGIN

   "Then you sleep a bit to let the routing complete."

QUOTE_END

In general count with this whenever you make use of a polling consumer:


   http://camel.apache.org/polling-consumer.html

Also another way of doing this is the usage of a

   java.util.concurrent.CountDownLatch

through which you can make sure that you do assert on something *after*
some
conditions have been already fulfilled for sure. If you look at the Camel's
own unit tests you will find pretty much of this pattern as well.

Greetings from the domain "ch" as well... :-)

Babak
	



>
>Thanks for your help.
>John
>
>
>
>--
>View this message in context:
>http://camel.465427.n5.nabble.com/mock-expectedMessageCount-0-resulting-in
>-a-false-positive-tp5723952p5724031.html
>Sent from the Camel - Users mailing list archive at Nabble.com.



Mime
View raw message