Feedback on #assert: vs. #assert:equals:

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

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 <[hidden email]> 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

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.

Nahuel

2015-10-22 12:15 GMT-03:00 Alexandre Bergel <[hidden email]>:
> 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-with-a-non-boolean-argument
>
> 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 <[hidden email]> 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
>
>