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 <[email protected]
<mailto:[email protected]>> wrote:
On Sat, Apr 30, 2011 at 4:20 PM, Mariano Martinez Peck
<[email protected] <mailto:[email protected]>> 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
