[Pharo-users] Feedback on #assert: vs. #assert:equals:
i.uhnak at gmail.com
Thu Oct 22 06:03:43 EDT 2015
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
self assert: collection isEmpty
self assert: collection size equals: 0
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.
On Thu, Oct 22, 2015 at 3:21 AM, 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
> 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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-users