SUnit debugging hint.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

SUnit debugging hint.

R. Clayton
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.


Reply | Threaded
Open this post in threaded view
|

Re: SUnit debugging hint.

Andreas.Raab
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.
>
>
>



TestCase-openDebuggerOnFailingTestMethod.st (404 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SUnit debugging hint.

Tom Phoenix
In reply to this post by R. Clayton
On 29 May 2006 18:01:46 -0400, R. Clayton <[hidden email]> wrote:

>   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

Perhaps I'm misunderstanding what you want. But did you try stepping
over the 'self halt', and then into the actual failing test method?

Hope this helps!

--Tom Phoenix

Reply | Threaded
Open this post in threaded view
|

Re: SUnit debugging hint.

stéphane ducasse-2
In reply to this post by R. Clayton
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.
>
>