How does the SUnit debug view, highlight lower down in the stack?

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

How does the SUnit debug view, highlight lower down in the stack?

Tim Mackinnon
I’ve been working on improving some of my testing techniques and the tools used to do that, and it highlighted something where I’m not clear on how it works. 
Sometime the debugger highlights a failure lower down in the stack (not just the stack frame directly below the signaller).

How does it do it? I can’t see what it does to achieve this - however curiously it differs between types of assert.

I.e. with: self assert: 2 =3 (it just shows the frame below)

Yet: self assert: 2 equals: 4 (shows two frames below, and actually directly shows where in the test failed - with no further clicks which is brilliant)

The photos (at the end) demonstrate what I mean - and I can see there is a defaultAction in TestFailure that pops open the debugger:

defaultAction

Processor activeProcess
debug: self signalerContext
title: self description


And if I try and do a similar thing for one of my own exceptions - but wind further down the stack manually (which TestFailure does’t do) like:

defaultAction
| triggerContext |
triggerContext := self signalerContext findContextSuchThat:
[ :context | context method selector = #doesNotUnderstand: ].
"Trigger the debugger where the failure happened"
Processor activeProcess
debug: (triggerContext ifNil: [ self signalerContext ])
title: self messageText

This gives me a debugger on the line of the failure (which I like), but the stack above this failure (which in my case was many frames deep) is gone (presumably as contexts only know their parent, and I’ve backed up through the parent chain). This is a bit confusing to understand how you got the error.

So I’m left wondering how #assert:equals: ends up highlighting further down. I’m missing some concept - and wondering if anyone knows? It’s not urgent - but a smalltalk’y curiosity about how our environment works.

Tim



The debugger that pops up for assert:


vs. The debugger that pops up for #assert:equals:

Reply | Threaded
Open this post in threaded view
|

Re: How does the SUnit debug view, highlight lower down in the stack?

Ben Coman


On Mon, 11 Mar 2019 at 17:31, Tim Mackinnon <[hidden email]> wrote:
I’ve been working on improving some of my testing techniques and the tools used to do that, and it highlighted something where I’m not clear on how it works. 
Sometime the debugger highlights a failure lower down in the stack (not just the stack frame directly below the signaller).

How does it do it? I can’t see what it does to achieve this - however curiously it differs between types of assert.

I.e. with: self assert: 2 =3 (it just shows the frame below)

Yet: self assert: 2 equals: 4 (shows two frames below, and actually directly shows where in the test failed - with no further clicks which is brilliant)

The photos (at the end) demonstrate what I mean - and I can see there is a defaultAction in TestFailure that pops open the debugger:

defaultAction

Processor activeProcess
debug: self signalerContext
title: self description


And if I try and do a similar thing for one of my own exceptions - but wind further down the stack manually (which TestFailure does’t do) like:

defaultAction
| triggerContext |
triggerContext := self signalerContext findContextSuchThat:
[ :context | context method selector = #doesNotUnderstand: ].
"Trigger the debugger where the failure happened"
Processor activeProcess
debug: (triggerContext ifNil: [ self signalerContext ])
title: self messageText

This gives me a debugger on the line of the failure (which I like), but the stack above this failure (which in my case was many frames deep) is gone (presumably as contexts only know their parent, and I’ve backed up through the parent chain). This is a bit confusing to understand how you got the error.

So I’m left wondering how #assert:equals: ends up highlighting further down. I’m missing some concept - and wondering if anyone knows? It’s not urgent - but a smalltalk’y curiosity about how our environment works.

I haven't dug deeply, but to get you started...
using the following as a test case
    TestCase subclass: #ATest ...

    ATest >> test1
self assert: 2 =3

    ATest >> test2
self assert: 2 equals: 4

If I run each by clicking on their test icons, the pre-debug windows look identical, 
so the difference occurs after clicking the <Debug> button.

Leaving the windows untouched for a moment,  
and presuming its something to do with identifying the #assert:equals message, 
use the Finder to search Source for that message and put a "self haltOnce"
of all the candidate methods.

Then click one <Debug> button, and one of those "self haltOnce"s is triggered.
Save that method again to reset the haltOnce, then click the other <Debug> button.
Now side-by-side trace through both debuggers looking for differences in execution.

cheers -ben

PastedGraphic-5.png (398K) Download Attachment
PastedGraphic-6.png (405K) Download Attachment