Le 22/10/15 12:03, Peter Uhnák a écrit :
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.
+1
Peter
On Thu, Oct 22, 2015 at 3:21 AM, Nahuel Garbezza <n.garbe...@gmail.com
<mailto:n.garbe...@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
