[Pharo-project] I am the only one who finds #assert:equals: oppostite to expected?

Andres Valloud avalloud at smalltalk.comcastbiz.net
Sat Apr 30 22:04:56 CEST 2011


When the expected answer is not a literal, then the order is not so 
important.  Usually, complex tests have expected answers that are not 
literals, and you end up with a method along the lines of

expectedAnswer := self doItOneWay.
actualAnswer := self doItTheOtherWay.
self assert: expectedAnswer = actualAnswer

or

expectedAnswer := self doItOneWay.
actualAnswer := self doItTheOtherWay.
self assert: actualAnswer = expectedAnswer

But, see, in this case the temporary value names remove the confusion, 
and then the order doesn't matter as much.  It seems to me the original 
issue is that the meaning of a message argument is implicit only in the 
order because the selector does not distinguish between the two provided 
arguments.  In short, the selector is vague because it does not help 
disambiguating the meaning just by reading the code aloud.

You can change the order if you want, but I suspect there's more to it 
than that.

My 2c of devalued Monopoly money printed on recycled newspaper... :).

Andres.


On 4/30/11 11:22 , Mariano Martinez Peck wrote:
> Thanks everybody, it is nice to see I am not alone..
> Yes, Stef, the API is the same, but the sematics is not. I mean, I
> muuuch prefer to change it, but indeed, there will be a change in the
> "behavior". What I mean is that all test cases that were using
> #assert:equals: in the "correct" way  (correct I mean to what SUnit
> says), then after will be "incorrect". I don't care. The only problem is
> that when they debugger the message will be incorrect.
> But it is as always....or improve or be backward compatibility....
>
> So... +1 to the change
>
> Here is the issue tracker:
> http://code.google.com/p/pharo/issues/detail?id=4129
>
> if we finally agree, I can submit the fix.
>
> Cheers
>
> Mariano
>
>
> On Sat, Apr 30, 2011 at 7:13 PM, Damien Cassou <damien.cassou at gmail.com
> <mailto:damien.cassou at gmail.com>> wrote:
>
>     On Sat, Apr 30, 2011 at 4:20 PM, Mariano Martinez Peck
>     <marianopeck at gmail.com <mailto:marianopeck at gmail.com>> wrote:
>      > testBlah
>      >     | universalAnswer |
>      >     universalAnswer := 30.
>      >     universalAnswer := universalAnswer + 11.
>      >     self assert: universalAnswer equals: 42.
>      >
>      > In this case, 42 is the "expected" and "universalAnswer" is the
>     "actual"
>      > value.
>      > I feel weird writing like this:
>      >
>      >     self assert: 42 equals: universalAnswer.
>
>     I think I'm responsible for this non sense, sorry about that. When I
>     put the parameters in this order, I thought the result would be
>     similar to JUnit in which 'expected' is always before 'actual'.
>     Unfortunately, it looks like I just forgot to read the whole sentence:
>     'self assert that something equals 42' reads much better than the
>     other way around. I don't think too much code depends on this
>     #assert:equals: method as it has only been introduced recently.
>
>     I vote for changing the order.
>
>     --
>     Damien Cassou
>     http://damiencassou.seasidehosting.st
>
>     "Lambdas are relegated to relative obscurity until Java makes them
>     popular by not having them." James Iry
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>



More information about the Pharo-project mailing list