Thanks again Harald...

On 7 Dec 2011, at 16:36, Harald Wellmann wrote:

> 2011/12/7 Glyn Normington <[email protected]>:
>> When an org.junit.Assert.assertEquals fails in a test I'm running under Pax
>> Exam, I get an unhelpful stack trace in the HTML test results. The testcase
>> is not present in the stack trace, so it's hard to see which assert failed.
>> (I can't see the 'right' stack trace anywhere else, e.g. in logs, for that
>> matter.) The full stack trace is immediately below.
>> 
>> I tried running under Eclipse and putting a breakpoint at
>> JUnit4TestRunner.java:263, but the caught exception was even more cryptic.
>> See further below (and apologies for the lack of formatting).
>> 
>> When I comment out the assertEquals in the testcase, the test passes both
>> under Gradle and under Eclipse, so I have the feeling that the test
>> configuration is reasonable.
>> 
>> Any suggestions?
>> 
> 
> A while ago I improved the error handling so that driver failures
> always include the full stack trace produced by a container failure,
> but this is included in 2.3.0.M1 and not in Pax Exam 2.2.0 which I
> assume you're using.

If I can't find another solution, I'll try 2.3.0.M1.

> 
> The RemoteBundleContext in your stack trace indicates that your test
> is running in the Pax Runner Container. To see what's really going on
> inside the container, you'd have to use remote debugging, see [1].

Hmmm. The heading of the test report says:
 
test:TestSpringBundleResolution.test:NativeContainer:org.eclipse.osgi.launch.EquinoxFactory@fe8c585

so I think I am running the native container as intended.

I'll try remote debugging as a last resort (i.e. not just yet ;-) ).

> 
> Then again, if assertTrue(true) produces an error, then maybe there's
> a communication problem, and the test itself is ok...

Sounds likely.

> 
> Or you're missing a runtime dependency inside the container so that
> your test class cannot be instantiated.

I tried prefixing the assert with:

if (1==0)

and the test still failed, so that theory is a distinct possibility.

> 
> [1] 
> http://team.ops4j.org/wiki/display/paxexam/FAQ#FAQ-WhydoestheJavadebuggernotstopatabreakpointIsetinmyPaxExamJUnittest%3F
> 
> Regards,
> Harald
> 
> _______________________________________________
> general mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/general


_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general

Reply via email to