[Pharo-project] #assert:equals:
This pattern is common in our tests: "self assert: a = b." I much prefer "self assert: a equals: b." It makes it easier to diagnose failing tests, especially if a or b are expressions with side-effects. Do you agree? Sean -- View this message in context: http://forum.world.st/assert-equals-tp4636050.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Fri, Jun 22, 2012 at 3:53 AM, Sean P. DeNigris <sean@clipperadams.com>wrote:
This pattern is common in our tests: "self assert: a = b."
I much prefer "self assert: a equals: b."
It makes it easier to diagnose failing tests, especially if a or b are expressions with side-effects. Do you agree?
I do. I use #assert:equals: in most of my tests.
Sean
-- View this message in context: http://forum.world.st/assert-equals-tp4636050.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Mariano http://marianopeck.wordpress.com
I never understood the problems :) Stef On Jun 22, 2012, at 3:53 AM, Sean P. DeNigris wrote:
This pattern is common in our tests: "self assert: a = b."
I much prefer "self assert: a equals: b."
It makes it easier to diagnose failing tests, especially if a or b are expressions with side-effects. Do you agree?
Sean
-- View this message in context: http://forum.world.st/assert-equals-tp4636050.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
me neither. a=b is clear enough for me. If I want more detail, I add a description. but perhaps I'm loosing something that I'm not seeing. Esteban On Jun 22, 2012, at 9:35 AM, Stéphane Ducasse wrote:
I never understood the problems :)
Stef
On Jun 22, 2012, at 3:53 AM, Sean P. DeNigris wrote:
This pattern is common in our tests: "self assert: a = b."
I much prefer "self assert: a equals: b."
It makes it easier to diagnose failing tests, especially if a or b are expressions with side-effects. Do you agree?
Sean
-- View this message in context: http://forum.world.st/assert-equals-tp4636050.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 2012-06-22, at 09:39, Esteban Lorenzano wrote:
me neither. a=b is clear enough for me. If I want more detail, I add a description. but perhaps I'm loosing something that I'm not seeing.
Esteban
error messages + inspect??? I hate to go and re-eavluate the code to see what was wrong during comparison... like that you keep the two arguments somewhere up in the stack and you can go and simply go and see what went wrong. consider self assert: self someExpressionReturningFalse = self someExpressionReturningTrue how the heck do you know what went wrong? assert:equals: is the thing to use. I don't like it particularly, it feels too java-ish, I prefer much more the "shoulder" framework written in bern. self someExpressionReturningFalse should = self someExpressionReturningTrue ËËËËËË that somehow feels much more natural to me :P
Camillo Bruni-3 wrote
I hate to go and re-eavluate the code to see what was wrong during comparison... ...self assert: self someExpressionReturningFalse = self someExpressionReturningTrue how the heck do you know what went wrong?
Yes, that's exactly it! Camillo Bruni-3 wrote
I don't like it particularly, it feels too java-ish, I prefer much more the "shoulder" framework written in bern. self someExpressionReturningFalse should = self someExpressionReturningTrue
+1! Re the framework, do you mean Phexample? I *really* like the matchers, like the one you mentioned above. Although I don't like the way tests build on each other. It's a great idea, but a failing given should cause the test to be skipped, which we don't have in Pharo (the best we can do is probably have it be an error, which is better than a failing test, but not by much) -- View this message in context: http://forum.world.st/assert-equals-tp4636050p4636136.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
So, is clarity when executing vs clarity when reading (because "a=b" is a lot clearer that "a equals: b"). Is that? Don't get me wrong... I'm not struggling against it, I'm just trying to understand the issue. Esteban On Jun 22, 2012, at 2:56 PM, Sean P. DeNigris wrote:
Camillo Bruni-3 wrote
I hate to go and re-eavluate the code to see what was wrong during comparison... ...self assert: self someExpressionReturningFalse = self someExpressionReturningTrue how the heck do you know what went wrong?
Yes, that's exactly it!
Camillo Bruni-3 wrote
I don't like it particularly, it feels too java-ish, I prefer much more the "shoulder" framework written in bern. self someExpressionReturningFalse should = self someExpressionReturningTrue
+1!
Re the framework, do you mean Phexample? I *really* like the matchers, like the one you mentioned above. Although I don't like the way tests build on each other. It's a great idea, but a failing given should cause the test to be skipped, which we don't have in Pharo (the best we can do is probably have it be an error, which is better than a failing test, but not by much)
-- View this message in context: http://forum.world.st/assert-equals-tp4636050p4636136.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 2012-06-22, at 16:51, Esteban Lorenzano wrote:
So, is clarity when executing vs clarity when reading (because "a=b" is a lot clearer that "a equals: b"). Is that? Don't get me wrong... I'm not struggling against it, I'm just trying to understand the issue.
Esteban
yes :) a should = b would be somehow in the middle :P
I'm working on this. Slowly. -Steven On 2012-06-22, at 11:13 AM, Camillo Bruni wrote:
On 2012-06-22, at 16:51, Esteban Lorenzano wrote:
So, is clarity when executing vs clarity when reading (because "a=b" is a lot clearer that "a equals: b"). Is that? Don't get me wrong... I'm not struggling against it, I'm just trying to understand the issue.
Esteban
yes :)
a should = b
would be somehow in the middle :P
Steven Baker wrote
I'm working on this. Slowly.
The Phexample matchers are very close to Rspec and work well... -- View this message in context: http://forum.world.st/assert-equals-tp4636050p4636176.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (6)
-
Camillo Bruni -
Esteban Lorenzano -
Mariano Martinez Peck -
Sean P. DeNigris -
Steven R. Baker -
Stéphane Ducasse