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. |
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 |
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 |
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. > > |
Free forum by Nabble | Edit this page |