I "fixed" all countDownLatch.await(timeout, timeUnit) calls and check the return value as assertTrue(countDownLatch.await(timeout, timeUnit)). All tests still pass at this time.
I didn't got the point that the onException() definition was not triggered, when we throw an AssertionFailureError or ComparisonFailure inside a Processor. In the unit test I improved a few day ago the problem was, that we didn't checked whether the exchange was done successfully or not. Is this what you mean? Best, Christian On Thu, Mar 1, 2012 at 3:14 PM, Babak Vahdat <babak.vah...@swissonline.ch>wrote: > Hi > > It seems there're still other false-positive unit tests as well one of > which > I fixed > right before [1] as I saw the JMS Header discussion @ user forum. > > IMHO in *almost* all cases we should assertTrue() on ALL > CountDownLatch.await() calls > to return true (the timeout should not elapse). And also using the > onException() clause > NEVER and EVER rely on: > > junit.framework.AssertionFailedError, org.junit.ComparisonFailure or the > likes, BUT only > on: > > java.lang.AssertionError > > In the case of the test mentioned we had: > > onException(AssertionFailedError.class) > > However the thrown exception through JUnit was org.junit.ComparisonFailure > while we did > assertEquals() inside the processor so that the onException() clause did > *not* trigger at all! > > I hope I'm *definitely* wrong but somehow I've got the feeling that > there're > much more such > unit-tests out there in Camel source itself! > > As the test behaved false positive we didn't realize it by CAMEL-1871. BTW, > maybe it's > just a matter of my personal taste but I HATE false-positive tests :-((( > > [1] http://svn.apache.org/viewvc?view=revision&revision=1295573 > > Babak > > -- > View this message in context: > http://camel.465427.n5.nabble.com/About-false-positive-Test-inside-Camel-source-tp5483171p5527960.html > Sent from the Camel Development mailing list archive at Nabble.com. >
