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@gmail.com>wrote:
On Sat, Apr 30, 2011 at 4:20 PM, Mariano Martinez Peck <marianopeck@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