Dear Nahuel, I think you are raising in excellent point. I think that assert: should raise an assertion error when a non-boolean is provided. I have added an entry: https://pharo.fogbugz.com/f/cases/16847/assert-should-not-raise-an-error-wit... Tomorrow we have a sprint, this is like an easy thing to fix. We will work on it! Thanks, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Oct 21, 2015, at 10:21 PM, Nahuel Garbezza <n.garbezza@gmail.com> wrote:
Hi everyone,
I'm using Pharo for teaching and we use TDD since the beginning. I've noticed that if you use #assert: on a test, like this:
self assert: object messageReturningBoolean
It gives you strange results in terms of feedback if the result is not a boolean. I would expect an AssertionFailed (yellow test) but I got a NonBooleanReceiver (red test).
What we do in our course is to write the assertion like this:
self assert: object messageReturningBoolean equals: true
So we got a "expected true but was <other object>" error which is a lot more helpful to the students.
I was thinking that is better to have #assert: implementation based on #assert:equals:. It is like saying #assert:equals: is the "primitive" assertion message, which makes sense to me since you are always comparing if an object is equal to another, there's no reason to handle the booleans' case differently.
What do you think?
Thank you!
Nahuel