Capture call stack of failing tests, or navigate to failing test not the test failure location

[David Millington]

I have JCLDebug set up in my test project, and so when an error occurs double-clicking the entry in TestInsight takes you to the failing line. This is fine when the failure is a Check() error, but not so good when it's an exception.

The reason is that double-clicking takes you to place the exception was caused - eg, somewhere in System, perhaps - not the failing test or test line. It would be useful to either override the location and force the double-click to go to the test itself, and/or capture the stack and allow the user to navigate to any spot in it.

[David Millington]

Or, using DUnit, if you use CheckEquals and it fails, double-clicking the test will take you to TAbstractTest.CheckEquals not to the line that failed.

I really want to go to the line in the failing test case method, and so if you can capture the call stack and find it that would be very useful. Ditto for then allowing navigation up/down the stack to the actual failure point.

[Stefan Glienke]

Actually CheckEquals should raise the ETestFailure exception at its calleraddress/returnaddress.

Capturing the callstack can be done with jcldebug or any other of these libraries aswell. Only the navigating to individual lines from the callstack would be the issue.

[Stefan Glienke]

Issue #31 was marked as a duplicate of this issue.

[Honza Rameš]

Proposed changes:

• unitname should not be changed (breaks selection of the method for testing if exception occurs in nested call).
• Double clicking on test method should always show the location in the test method (even in times when the exact position in the test method is not known) not the location where the exception occurred.
• Double clicking on the exception/failure message should show the actual location of the exception (the nested one).
• Entire callstack should be nested under the test failure message in the testing tree.

[Honza Rameš]

added support for sending complete stack trace of the failure

This comes with refactoring of transfer object, LineNumber was removed and all information is sent as a stack trace. OpenTestInSourceEditor was also improved to allow easier navigation based on which node was selected. If the failure contains stack trace it is placed as subnodes of the failure message.

Currently only LeakCheck supports sending of full stack trace but other features should work just fine with madExcept and JCL debug.

See issue #26

→ <<cset acc6afa45bc9>>

[Stefan Glienke]

Should also be solved in this context: #95