Hi Christian,
Both
junit.framework.AssertionFailedError
org.junit.ComparisonFailure
extend java.lang.AssertionError
Now inside Processors by [1] we do some assertEquals() which by it's failure
would throw org.junit.ComparisonFailure *however* we used to do:
onException(junit.framework.AssertionFailedError)...
which was *not* triggered *at all* as JUnit did throw
org.junit.ComparisonFailure so that
errors.expectedMessageCount(0);
did pass as junit.framework.AssertionFailedError has *no* direct type
relationship with org.junit.ComparisonFailure. On the other hand we make use
of the jms consumer by this test so that the thrown AssertionErrors was
happening inside the AsyncMessageListenerInvoker threads of spring DMLC
(DefaultMessageListenerContainer). If for example we had a usage of the
direct consumer then we had realized the failed asserts as we had consumed
inside the *main* thread.
Just to see the failed assertion by this test get the previous version of it
on your workspace and set a breakpoint on the line *116* and you should see
how the assertions did fail *but* the test *passes*.
In general it's a sharp corner of using JUnit not being able to report
failed asserts not happening inside main thread. There're many places on the
web [2] talking about this.
[1]
https://svn.apache.org/repos/asf/camel/trunk/components/camel-jms/src/test/java/org/apache/camel/component/jms/JmsHeaderFilteringTest.java
[2]
http://andrejserafim.wordpress.com/2010/10/07/testing-threads-with-junit/
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/About-false-positive-Test-inside-Camel-source-tp5483171p5535127.html
Sent from the Camel Development mailing list archive at Nabble.com.
