How to get the stack trace of a failed test?

[Joachim Durchholz]

Howdy,

First things first:
That's nice work with Infinitest. There aren't many Eclipse plugins
that work right out of the box like this one did.

I see Infinitest run, I see it report a failing test as it should, and
it even gives me an error marker at the point where the test failed
(an exception thrown). I like this very much!

What I'm missing is a way to get at the stack trace between point of
failure and start of the @Test-annotated function where the trouble
began, like in the JUnit view of Eclipse.
Currently, I'm forced to Alt-Enter the error message, copy the class
name from the Description field, close the dialog, Ctrl-Shift-T, paste
the class name, find the function mentioned in the error message, then
Alt-Shift-D T the function name to re-debug the failing test in the
JUnit view.

It's as awkward as it sounds, so: is there a better way?
Am I overlooking something? Is it on the Todo list?

I'm using the plugin as it comes on infinitest.github.com as of today.

[Ben Rady]

There should be a marker on the failing test. The quick fix menu for that marker should have an option to show the stack trace.

[David Gageot]

I confirm. I don't remember breaking that ;-)

David.

[Joachim Durchholz]

> On Thu, Apr 21, 2011 at 3:41 PM, Ben Rady <benr...@gmail.com> wrote:
> > There should be a marker on the failing test.

I'm not 100% sure what you mean with "on the failing test".
If you mean the declaration of the @Test-annotated function, then no,
I'm not seeing that.
If it's in the place where the test actually fails (AssertXxx call
site, exception throwing site), then yes, I see the error marker. It
does not have an associated Quick Fix for me though - there are
various Quick Fixes offered (refactoring stuff and a proposal from
Hibernate Tools), but nothing from Infinitest.

Any ideas where to look next?

Regards,
Jo

[David Gageot]

Hi,

Turned out it is broken. Changes in the MANIFEST.MF break the Quick-Fix feature

I so hate this osgi thing. For now, I've reverted the faulty commit. Tomorrow, I'll try to see

if any test could have prevented that to happen. Don't really know where to start.

David.

[Joachim Durchholz]

Fortunately for us, we're yet in the process of setting up a more test-driven process.
We found the problem while test driving Infinitest, we're not (yet) seriously affected by any problems there.

I'll be back on Tuesday, so I'm wishing everybody a happy Easter!
Jo

[Joachim Durchholz]

> Turned out it is broken. Changes in the MANIFEST.MF break the Quick-Fix
> feature
>
> I so hate this osgi thing. For now, I've reverted the faulty commit.

Just a quick notice:

I'm still seeing the Infinitest plugin at the version I installed
initially (5.1.89), and it doesn't try to update when I tell Eclipse
to update plugins.
(Unsurprisingly, I don't see a stack trace either in Quickfixes
either.)

Just FWIW, and to give feedback on potential trouble spots in the
release process.
Please ignore if no new release was supposed to happen yet :-)

Regards,
Jo

[David Gageot]

I just published 5.1.90

Can you try again ?

David.

[Joachim Durchholz]

On 26 Apr., 11:38, David Gageot <dgag...@gmail.com> wrote:
> I just published 5.1.90
>
> Can you try again ?

Executive summary: Did as requested, nothing happened.

Details:
- Help->Check for Updates says "No updates were found".
- Window->Preferences->Install/Update->Available Software Sites has
http://infinitest.github.com enabled
- Reload on that repository says "http://infinitest.github.com is
available
- Retrying Help->Check for Updates (in the hopes that the Reload
button invalidated stale cached data) just gave me another "No updates
were found."

Not sure what's happening there, my knowledge of the web site layout
for Eclipse's plugin update machinery is almost nil so my best guess
would be some caching headers in the HTTP pages are wrong (I'm sitting
behing a Squid proxy here).

[David Gageot]

I've just verified that it works ok.

The quid proxy might be the problem. Not sure I can do anything.

David.

[Joachim Durchholz]

On 26 Apr., 11:59, David Gageot <dgag...@gmail.com> wrote:
> The quid proxy might be the problem. Not sure I can do anything.

I suspect that the HTTP answer that github is sending contains
something that says "the version you loaded on Tuesday last week is
still okay". Squid uses such information to avoid reloading unchanged
data from the server.

If you know the URL that Eclipse actually uses in the HTTP request to
do the update, I might be able to figure out the cause.

Regards,
Jo

[David Gageot]

Try http://infinitest.github.com/site.xml
The XML file contains the version.

David.

[Joachim Durchholz]

> Tryhttp://infinitest.github.com/site.xml

> The XML file contains the version.

I'm getting the updated site.xml just okay via the browser, so it's
not a caching issue along the way.
I'm just reinstalling the plug-in - fortunately, that's a snap.

5.1.90 installed just okay, and it's working fine for me now,
including stack traces.

On a tangent:

The ergonomy is a bit off.
Eclipse users are used to see exception/stack traces in a permanently-
open view, so they can double-click up and down the call chain so they
can quickly identify the level at which the problem actually happened.
Hmm.... the JUnit plugin is already doing all this, and it's doing it
well. I'm wondering whether Infinitest could simply pass a test suite
to the JUnit plugin and lean back.
Just my 2 cents here :)

Regards,
Jo

[David Gageot]

I fully agree :-)

David.

On 26 avr. 2011, at 12:17, Joachim Durchholz <joachim....@hennig-fahrzeugteile.de> wrote: