This is why I pretty much stopped using #assert: altogether, however note that sometimes it is better to avoid boolean completely, because the feedback of it is low Imagine: self assert: collection isEmpty versus self assert: collection size equals: 0 versus self assert: collection asArray equals: #() The first one is in my opinion easiest to read and understand it's purpose, but if the test fails it provides the least amount of feedback, while the last one is complete opposite - hardest to read, but if it fails provides most of the feedback. So you need to look to strike a balance, however I do agree that `#assert: nonBoolean` should be a failing test and not an error. Peter On Thu, Oct 22, 2015 at 3:21 AM, 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