On Mon, 11 Mar 2019 at 17:31, Tim Mackinnon <tim@testit.works> 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