[BUG][FIX] SUnit Unwind error during process termination

Bernhard Pieber bernhard at pieber.com
Mon Nov 15 18:17:26 UTC 2004


I created a minimal test to show the "Unwind error during process
termination" which haunted me the other day. See
http://bugs.impara.de/bug_view_page.php?bug_id=0000501.

"Change Set:		UnwindErrorTest-bp
Date:			15 November 2004
Author:			Bernhard Pieber

This Change Set contains a TestCase which illustrates a problem with
SUnit. Do the following:
- Run UnwindErrorTest in SUnit Test Runner.
- Click on the failing UnwindErrorTest>>#test. You get a debugger.
- Click on Over. You get a second debugger.
- Close this second debugger.
- Close the first debugger. You get a third debugger: Unwind error
during termination.
- Closing this debugger does not work. You have to proceed."

I assume that this behavior is a bug? I then compared the Squeak SUnit
implementation with that of the other Smalltalks (VA, VW and Dolphin)
and saw that it was different. I tried out what happens if I revert this
to the standard implementations. It turns out that I cannot reproduce
the Unwind error any more.

"Change Set:		SUnitDebugAsFailure-bp
Date:			15 November 2004
Author:			Bernhard Pieber

This Change Set reverts the implementation of debugAsFailure to the
standard SUnit one. This has three effects:
- When you debug a failing tests, you get a debugger on a halt. You have
to proceed to get the Test failed debugger. This is not so nice.
- The Test failed debugger runs to the failing assertion and not only to
the first message send of the failing method. This is nice for test
methods with many assertions.
- The Unwind error during termination does not happen any more. See
Change Set UnwindErrorTest-bp for details."

All in all, it seems to me that the standard implementation is better
for the following reasons:
- It is the same like in at least three of the other dialects.
- I could not reproduce the unwind error anymore.
- While I have to proceed the first debugger with the halt, it then runs
to the first failing assertion. So the number of clicks stays the same.

I wonder what was the reason for the special implementation in the first
place. I assume it was to avoid the first debugger on the halt? Or was
there any other reason? Did I miss something obvious?

Curiously,
Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: C:\Entwicklung\Squeak\3.8\UnwindErrorTest.bp.1.cs
Type: application/octet-stream
Size: 362 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20041115/6e61c603/UnwindErrorTest.bp.1.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: C:\Entwicklung\Squeak\3.8\SUnitDebugAsFailure-bp.2.cs
Type: application/octet-stream
Size: 1638 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20041115/6e61c603/SUnitDebugAsFailure-bp.2.obj


More information about the Squeak-dev mailing list