<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:large">Hi Levente,<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 12, 2020 at 10:59 AM Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div style="font-size:large">Hi Levente,<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 9, 2020 at 4:04 PM Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Eliot,<br>
<br>
On Fri, 9 Oct 2020, Eliot Miranda wrote:<br>
<br>
> Hi All,<br>
> <br>
> moving code from a test into a workspace and back is painful because Object does not implement assert:equals: or assert:equals:description: even though it implements assert:description:. So one has to edit out the<br>
> equals: moving to the workspace and edit it back in again on the way back. I'd like to suggest implementing Object>>assert:equals: and Object>>assert:equals:description: but I won't, because someone is bound to criticise it<br>
> as being too green or ill considered or some other depressing BS.<br>
<br>
In my opinion, it would be better to get rid of #assert:equals: and <br>
#assert:equals:description:. Many find the order of its arguments <br>
confusing, and they are only good to help tracking down what failed.<br>
If #assert: could give information about it's argument: the source code<br>
and probably the values of the variables in it, then #assert:equals: would <br>
simply become unnecessary.<br></blockquote><div><br></div><div style="font-size:large">I couldn't agree more. I *hate* assert:equals: being, for me, the wrong way round. We would need to provide an abstraction around extracting the parse tree for an argument, which shouldn't be too hard. Let me take a look at this and see if I can provide something simple and robust.</div><div style="font-size:large"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
For example<br>
<br>
| x y |<br>
x := 'foo'.<br>
y := 1.<br>
self assert: x = y.<br>
<br>
would signal an exception with the message 'Assertion failed: x = y (x = <br>
''foo'', y = 1)' instead of just 'Assertion failed'.<br></blockquote></div></div></blockquote><div><br></div><div class="gmail_default" style="font-size:large">Having thought about it a bit the problem is more difficult than it appears. If the form of an assert is</div><div class="gmail_default" style="font-size:large"> self assert: exprA = exprB</div><div class="gmail_default"><span style="font-size:large">then in general only the result</span><font size="4"><font face="arial, sans-serif"> of <span style="color:rgb(0,0,0)">exprA = exprB </span>is available. exprA and exprB may have only been evaluated on the stack and not bound to variables. So no matter tha introspection makes it trivial to derive the parse node and present the text for the expression: 'exprA = e</font>xprB' there is no way to retrieve the values of either exprA or exprB because they have been consumed and replaced by the result of their comparison. This is what assert:equals: does; it binds both the actual and expected values to the arguments of assert:equals: and then performs the comparison. So, absent time reversal debugging machinery (which has costs and is unlikely to be attractive for general use in running test suites which are > 99% correct most of the time) we're stuck with assert:equals:.</font></div><div class="gmail_default"><font size="4"><br></font></div><div class="gmail_default"><font size="4">So things to think about are perhaps</font></div><div class="gmail_default"><font size="4" face="arial, sans-serif">- a sibling of assert:equals: which takes its arguments in the opposite order</font></div><div class="gmail_default"><font size="4" face="arial, sans-serif">- appealing to the SUnit community to reverse the order of arguments to assert:equals:, plus a rewrite rule that reversed the obvious cases where the first argument is a literal constant.</font></div><div class="gmail_default"><font size="4" face="arial, sans-serif">- seeing if assert:equals: could infer the order of its arguments; this would require some analysis. For how many assert:equals: cases can it easily be determined if one or other of the arguments is the expected? How many cases are ambiguous? Are any undecidable? etc...</font></div><div class="gmail_default"><font size="4" face="arial, sans-serif">- implementing "backwards in time" debugging for the Test Runner when one selects a failing or erroring case. This might be no more than instrumenting the method to place breakpoints before comparisons whose results are consumed by assert: variants and running up until the break. This could be somewhat analogous to toggle break on entry in that adding/removing the pre comparison breakpoints would be automatic. And one might be able to do it by mapping comparisons to comparisons for asserts. e.g. consider:</font></div><div class="gmail_default"><font size="4" face="arial, sans-serif"><br></font></div><div class="gmail_default"><font size="4" face="arial, sans-serif"> self assert: a = b (along with >, <, >= et al)</font></div><div class="gmail_default"><font size="4" face="arial, sans-serif">transformed into</font></div><div class="gmail_default"><font size="4" face="arial, sans-serif"> self assert: (a compareEqualForAssert: b)</font></div><div class="gmail_default"><font face="arial, sans-serif"><font size="4">where </font><span style="color:rgb(0,0,0);font-size:medium">compareEqualForAssert: answers a structured object (AssertResult?) holding onto a, b, and the result of the comparison. AssertResult would answer its result in response to value. So assert methods (that already send value to coerce blocks and booleans to booleans) could send value to the argument, and then if that was false, query to see if the argument was an AssertResult and xtract a more informative error message if so.</span></font></div><div class="gmail_default"><span style="color:rgb(0,0,0);font-size:medium"><font face="arial, sans-serif"><br></font></span></div><div class="gmail_default"><span style="color:rgb(0,0,0);font-size:medium"><font face="arial, sans-serif">All this is fun, and could function in the context of SUnit. It does nothing to answer my problem of running asserts in Workspaces. However, that was thoughtless on my part. All I have to remember to do is inspect an instance of a TestCase class and evaluate my doit in that inspector. So for the SocketTesxts if I had had my wits about me I would have simply inspected SocketTest new and then could use ll of SUnit's assert machinery in a doit in the inspector.</font></span></div><div class="gmail_default"><font size="4" face="arial, sans-serif"><br></font></div><div class="gmail_default"><font size="4"><br></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Levente<br></blockquote></div><br><div dir="ltr"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>
</blockquote></div><div><br></div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div></div></div>