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 <alexandre.ber...@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: > 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 <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 > >
