[Pharo-project] I am the only one who finds #assert:equals: oppostite to expected?
Hi guys. I always code my tests something like this: 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 don't know why...but I do..the same as when doing should: [] raise: Error. In that case you put the "actual" first and the "expected" at the end... ok....the "problem" is that assert:equals: is in fact: asserts: expected equals: actual instead of asserts: actual equals: expected So, with my test I would receive a description in the debugger that says "'Expected 41 but was 42.'" which is completely the opposite. Of course, if I write my tests in the way I don't like, that is: self assert: 42 equals: universalAnswer. then i got the correct message "'Expected 42 but was 41.'" I don't pretend pharo change this because I guess it is standard, and blah blah blah. But senders of #assert:equals: should both, some written as mine (so the message is incorrect for them) and some correct. In addition, I think it is a problem of the selector name. If we could make it clearer, the won't be necessary to confuse "actual" with "expected". Cheers -- Mariano http://marianopeck.wordpress.com
It feels backwards to me too, in the same way that "one plus one equals two" feels more natural than "two equals one plus one". -- Cheers, Peter. On 30 apr 2011, at 16:20, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Hi guys. I always code my tests something like this:
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 don't know why...but I do..the same as when doing should: [] raise: Error. In that case you put the "actual" first and the "expected" at the end...
ok....the "problem" is that assert:equals: is in fact: asserts: expected equals: actual instead of asserts: actual equals: expected
So, with my test I would receive a description in the debugger that says "'Expected 41 but was 42.'" which is completely the opposite. Of course, if I write my tests in the way I don't like, that is: self assert: 42 equals: universalAnswer.
then i got the correct message "'Expected 42 but was 41.'"
I don't pretend pharo change this because I guess it is standard, and blah blah blah. But senders of #assert:equals: should both, some written as mine (so the message is incorrect for them) and some correct.
In addition, I think it is a problem of the selector name. If we could make it clearer, the won't be necessary to confuse "actual" with "expected".
Cheers
-- Mariano http://marianopeck.wordpress.com
Mariano, I agree, I have NEVER written self assert: expected = actual description: 'expected should equal this result but is not'. That makes me think of this story: In my company, C++ "experts" decided to nether write bool isActive ... if (isActive) { ... } because they pretend every condition must be a test (== <= etc...) to be sure it's a boolean... So they ended up wrting this kind of stupid thing: if (isActive==true) { ... } But I told them : what if you forget one of the equal signs ? Isn't it worse than above ? A lint rule would be so much better ! They said ah, yes you're right, we now gonna write it: if( true==isActive ) { ... } Sometimes, I see loops written like this while(false==isNotActive) { ... } and scratch my head a few seconds. I think our minds are just different... Nicolas 2011/4/30 Peter Hugosson-Miller <oldmanlink@gmail.com>:
It feels backwards to me too, in the same way that "one plus one equals two" feels more natural than "two equals one plus one".
-- Cheers, Peter. On 30 apr 2011, at 16:20, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Hi guys. I always code my tests something like this:
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 don't know why...but I do..the same as when doing should: []Â raise: Error. In that case you put the "actual" first and the "expected" at the end...
ok....the "problem" is that assert:equals: is in fact:  asserts: expected equals: actual instead of asserts: actual equals: expected
So, with my test I would receive a description in the debugger that says "'Expected 41 but was 42.'" which is completely the opposite. Of course, if I write my tests in the way I don't like, that is: Â self assert: 42 equals: universalAnswer.
then i got the correct message "'Expected 42 but was 41.'"
I don't pretend pharo change this because I guess it is standard, and blah blah blah. But senders of #assert:equals: should both, some written as mine (so the message is incorrect for them) and some correct.
In addition, I think it is a problem of the selector name. If we could make it clearer, the won't be necessary to confuse "actual" with "expected".
Cheers
-- Mariano http://marianopeck.wordpress.com
mariano since the API is the same I guess that we can change to get the behavior you expect. I'm still convinced that we should develop another testing framework because just to be compatible with SUnit we are bound to never change. At brest I discuss and gave a list of features to niall and I still do not know what happened to them.... Stef
Hi guys. I always code my tests something like this:
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 don't know why...but I do..the same as when doing should: [] raise: Error. In that case you put the "actual" first and the "expected" at the end...
ok....the "problem" is that assert:equals: is in fact: asserts: expected equals: actual instead of asserts: actual equals: expected
So, with my test I would receive a description in the debugger that says "'Expected 41 but was 42.'" which is completely the opposite. Of course, if I write my tests in the way I don't like, that is: self assert: 42 equals: universalAnswer.
then i got the correct message "'Expected 42 but was 41.'"
I don't pretend pharo change this because I guess it is standard, and blah blah blah. But senders of #assert:equals: should both, some written as mine (so the message is incorrect for them) and some correct.
In addition, I think it is a problem of the selector name. If we could make it clearer, the won't be necessary to confuse "actual" with "expected".
Cheers
-- Mariano http://marianopeck.wordpress.com
You are not alone on this. On Sat, Apr 30, 2011 at 10:20 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Hi guys. I always code my tests something like this:
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 don't know why...but I do..the same as when doing should: [] raise: Error. In that case you put the "actual" first and the "expected" at the end...
ok....the "problem" is that assert:equals: is in fact: asserts: expected equals: actual instead of asserts: actual equals: expected
So, with my test I would receive a description in the debugger that says "'Expected 41 but was 42.'" which is completely the opposite. Of course, if I write my tests in the way I don't like, that is: self assert: 42 equals: universalAnswer.
then i got the correct message "'Expected 42 but was 41.'"
I don't pretend pharo change this because I guess it is standard, and blah blah blah. But senders of #assert:equals: should both, some written as mine (so the message is incorrect for them) and some correct.
In addition, I think it is a problem of the selector name. If we could make it clearer, the won't be necessary to confuse "actual" with "expected".
Cheers
-- Mariano http://marianopeck.wordpress.com
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
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
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@gmail.com <mailto:damien.cassou@gmail.com>> wrote:
On Sat, Apr 30, 2011 at 4:20 PM, Mariano Martinez Peck <marianopeck@gmail.com <mailto: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
On Apr 30, 2011, at 8:22 PM, 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.
why? not? I'm confused.
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
On Sun, May 1, 2011 at 1:10 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
On Apr 30, 2011, at 8:22 PM, 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.
why?
Right now the API is the method assert: expected equals: actual ^ self assert: (expected = actual) description: (self comparingStringBetween: expected and: actual) Which description message is "Expected: expected but was actual" Now....we want to change it to: assert: actual equals: expected ^ self assert: (expected = actual) description: (self comparingStringBetween: expected and: actual ) So...the only thing we change is the order in the parameters....the question is... do you condiser that changing the API ? Cheers Mariano
not? I'm confused.
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
-- Mariano http://marianopeck.wordpress.com
On Sun, May 1, 2011 at 2:50 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
So...the only thing we change is the order in the parameters....the question is... do you condiser that changing the API ?
I think this is changing the API because the contract of the method changes. But, it's an important change and it has a limited impact: - only error messages for non passing tests will be affecting - there are few senders of this message - among the existing senders, a lot of them use the API the wrong way (which means there code will get fixed automatically when we update the API :-)). -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
On Sun, May 1, 2011 at 3:49 PM, Damien Cassou <damien.cassou@gmail.com>wrote:
On Sun, May 1, 2011 at 2:50 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
So...the only thing we change is the order in the parameters....the question is... do you condiser that changing the API ?
I think this is changing the API because the contract of the method changes. But, it's an important change and it has a limited impact:
- only error messages for non passing tests will be affecting
exactly
- there are few senders of this message
yes, I checked that too
- among the existing senders, a lot of them use the API the wrong way (which means there code will get fixed automatically when we update the API :-)).
exactly :) The other possibily is to forget about actual and expected and let the message be soemthing like 'Assertion failed: (' , actual asString , ') ~= (' , expected asString , ')' or 'Assertion failed: (' , expected asString , ') ~= (' , actual asString , ')' But still...I prefer the previous one 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
this is a detail. Fix it fast and pass to the next important point. On May 1, 2011, at 3:54 PM, Mariano Martinez Peck wrote:
On Sun, May 1, 2011 at 3:49 PM, Damien Cassou <damien.cassou@gmail.com> wrote: On Sun, May 1, 2011 at 2:50 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
So...the only thing we change is the order in the parameters....the question is... do you condiser that changing the API ?
I think this is changing the API because the contract of the method changes. But, it's an important change and it has a limited impact:
- only error messages for non passing tests will be affecting
exactly
- there are few senders of this message
yes, I checked that too
- among the existing senders, a lot of them use the API the wrong way (which means there code will get fixed automatically when we update the API :-)).
exactly :)
The other possibily is to forget about actual and expected and let the message be soemthing like
'Assertion failed: (' , actual asString , ') ~= (' , expected asString , ')'
or
'Assertion failed: (' , expected asString , ') ~= (' , actual asString , ')'
But still...I prefer the previous one 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
Done http://code.google.com/p/pharo/issues/detail?id=4129 On Sun, May 1, 2011 at 3:38 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
this is a detail. Fix it fast and pass to the next important point.
On May 1, 2011, at 3:54 PM, Mariano Martinez Peck wrote:
On Sun, May 1, 2011 at 3:49 PM, Damien Cassou <damien.cassou@gmail.com>
wrote:
On Sun, May 1, 2011 at 2:50 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
So...the only thing we change is the order in the parameters....the question is... do you condiser that changing the API ?
I think this is changing the API because the contract of the method changes. But, it's an important change and it has a limited impact:
- only error messages for non passing tests will be affecting
exactly
- there are few senders of this message
yes, I checked that too
- among the existing senders, a lot of them use the API the wrong way (which means there code will get fixed automatically when we update the API :-)).
exactly :)
The other possibily is to forget about actual and expected and let the message be soemthing like
'Assertion failed: (' , actual asString , ') ~= (' , expected asString , ')'
or
'Assertion failed: (' , expected asString , ') ~= (' , actual asString , ')'
But still...I prefer the previous one 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
-- Mariano http://marianopeck.wordpress.com
you will see the problem in the error description... it will be backwards And it has some redefinitions in some subclasses, I don´t understand why :-) On Sat, Apr 30, 2011 at 3:22 PM, Mariano Martinez Peck < marianopeck@gmail.com> 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@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
-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*
I use temporary value names such as expectedAnswer and actualValue. Then I feel there's no confusion. On 4/30/11 7:20 , Mariano Martinez Peck wrote:
Hi guys. I always code my tests something like this:
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 don't know why...but I do..the same as when doing should: [] raise: Error. In that case you put the "actual" first and the "expected" at the end...
ok....the "problem" is that assert:equals: is in fact: asserts: expected equals: actual instead of asserts: actual equals: expected
So, with my test I would receive a description in the debugger that says "'Expected 41 but was 42.'" which is completely the opposite. Of course, if I write my tests in the way I don't like, that is: self assert: 42 equals: universalAnswer.
then i got the correct message "'Expected 42 but was 41.'"
I don't pretend pharo change this because I guess it is standard, and blah blah blah. But senders of #assert:equals: should both, some written as mine (so the message is incorrect for them) and some correct.
In addition, I think it is a problem of the selector name. If we could make it clearer, the won't be necessary to confuse "actual" with "expected".
Cheers
-- Mariano http://marianopeck.wordpress.com
participants (8)
-
Andres Valloud -
Damien Cassou -
Hernan Wilkinson -
Mariano Martinez Peck -
Nicolas Cellier -
Peter Hugosson-Miller -
Sean Allen -
Stéphane Ducasse