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
|