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 >
