I have a look on the latch.await(...) calls and changed them. Running a build at the moment to see if we really have some wrong-positiv tests...
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. >
