SUnit debugging hint.

R. Clayton rvclayton at acm.org
Mon May 29 22:01:46 UTC 2006


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