This is some *really* bad UI design in the test runner. It puts you in a 
place *before* the test is actually executed (e.g., the halt is before 
anything interesting has happened) and you need to "proceed" to get to 
the place where you want it, e.g., where the test failure happens.

BTW, this behavior has been driving me totally nuts over time and I've 
now kicked this out of any images I use - install the attached changes 
to do the same.

Cheers,
   - Andreas

R. Clayton wrote:
> When this test
> 
>   testStartSymbol
> 
>     self assert: lambda startSymbol = 'lambda'
> 
> gets run by SUnit, it produces this yellow-bar error:
> 
>   ContextFreeGrammarTests>>#testStartSymbol
> 
> Clicking on that line brings up the debugger with the following stack trace:
> 
>   ContextFreeGrammarTests(Object)>>halt
>   ContextFreeGrammarTests(TestCase)>>openDebuggerOnFailingTestMethod
>   [] in ContextFreeGrammar Tests(TestCase)>>runCaseAsFailure: {[self setUp.
>     self openDebuggerOnFailingTestMethod]}
>   BlockContext>>ensure:
>   BlockContext>>sunitEnsure:
>   ContextFreeGrammar Tests(TestCase)>>runCaseAsFailure:
>   ContextFreeGrammar Tests(TestCase)>>debugAsFailure
>   TestRunner>>debugFailureTest:
>   PluggableListMorph>>changeModelSelection:
>   PluggableListMorph>>mouseUp:
>   PluggableListMorph(Morph)>>handleMouseUp:
>   MouseButtonEvent>>sentTo:
>   PluggableListMorph(Morph)>>handleEvent:
>   PluggableListMorph(Morph)>>handleFocusEvent:
>   [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self.  
>     ActiveEvent := anEvent.  result := focusHolder     han...]}
>   [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]}
>   BlockContext>>on:do:
>   PasteUpMorph>>becomeActiveDuring:
>   HandMorph>>sendFocusEvent:to:clear:
>   HandMorph>>sendEvent:focus:clear:
> 
> My question is: how do I get to testStartSymbol's execution context?  If I
> click on the first line (ContextFreeGrammarTests(Object)>>halt) the debugger
> puts me in
> 
>   halt
>     "This is the typical message to use for inserting breakpoints during 
>     debugging. It behaves like halt:, but does not call on halt: in order to 
>     avoid putting this message on the stack. Halt is especially useful when 
>     the breakpoint message is an arbitrary one."
> 
>     Halt signal
> 
> Clicking on the next line puts me in
> 
>   openDebuggerOnFailingTestMethod
>     "SUnit has halted one step in front of the failing test method. Step over
>      the 'self halt' and send into 'self perform: testSelector' to see the
>      failure from the beginning"  
> 
>      self
>           halt;
>           performTest
> 
> None of the other lines are close to where I want to go.  If I force a red-bar
> error by putting 1/0 in startSymbol, the debugger stack trace looks like
> 
>   SmallInteger>>/
>   ContextFreeGrammar>>startSymbol
>   ContextFreeGrammar Tests>>testStartSymbol
>   ContextFreeGrammar Tests(TestCase)>>performTest
>   [] in ContextFreeGrammar Tests(TestCase)>>runCase 
>     {[self setUp.  self performTest]}
>   BlockContext>>ensure:
>   BlockContext>>sunitEnsure:
>   ContextFreeGrammar Tests(TestCase)>>runCase
>   [] in ContextFreeGrammar Tests(TestCase)>>debug 
>     {[(self class selector: testSelector) runCase]}
>   BlockContext>>ensure:
>   BlockContext>>sunitEnsure:
>   ContextFreeGrammar Tests(TestCase)>>debug
>   TestRunner>>debugErrorTest:
>   PluggableListMorph>>changeModelSelection:
>   PluggableListMorph>>mouseUp:
>   PluggableListMorph(Morph)>>handleMouseUp:
>   MouseButtonEvent>>sentTo:
>   PluggableListMorph(Morph)>>handleEvent:
>   PluggableListMorph(Morph)>>handleFocusEvent:
>   [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self.  
>     ActiveEvent := anEvent.  result := focusHolder     han...]}
> 
> and the second and third lines from the top give me what I want.  Why the
> difference in stack traces? 
> 
> This is on squeak 3.8, update 6665 from a debian testing system.
> 
> 
> 

-------------- next part --------------
'From Croquet1.0beta of 11 April 2006 [latest update: #1] on 29 May 2006 at 5:12:40 pm'!

!TestCase methodsFor: 'running' stamp: 'ar 5/29/2006 17:12'!
openDebuggerOnFailingTestMethod
	"SUnit has halted one step in front of the failing test method. Step over the 'self halt' and 
	 send into 'self perform: testSelector' to see the failure from the beginning"

	self
"		halt; "
		performTest! !