[Pharo-users] Feedback on #assert: vs. #assert:equals:

Nahuel Garbezza n.garbezza at gmail.com
Fri Oct 23 07:33:43 EDT 2015

Thanks for the answers, and for addressing this soon :)

I would like to participate on the sprint but I can't make it this time.


2015-10-22 12:15 GMT-03:00 Alexandre Bergel <alexandre.bergel at me.com>:
> 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:
> 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 at gmail.com>
> 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
> 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
> an object is equal to another, there's no reason to handle the booleans'
> case differently.
> What do you think?
> Thank you!
> Nahuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20151023/78a6e3eb/attachment.html>

More information about the Pharo-users mailing list