SUnit debugging hint.

stéphane ducasse ducasse at iam.unibe.ch
Tue May 30 07:27:42 UTC 2006


in which version of Squeak are you working?
Did you try with the new testRunner?

Stef

On 30 mai 06, at 00:01, 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.
>
>




More information about the Squeak-dev mailing list