[email protected] wrote: >> TestCase>>assert:, by convention, accepts a Boolean, and could >> be extended to also accept a block (and apparently has been so >> extended in Squeak). > > I see. I _think_ the idea of having it more 'compatible' with other > dialects changing it back to accept a Boolean and keeping > TestCase>>should: aBlock is a better way.
Agreed. [...] >> I don't know how widely used Object>>assert: is. Perhaps we >> could have a different selector for that which takes a >> block. > > I don't either, but I find strange the complete hierarchy of classes > of Pharo having a method assert: available. Perhaps I'm blindfolded > and Pharo and Squeak have found a wider use for assertions? Ah, sorry for the confusion. What I'm talking about here (and I assumed Alexandre was as well, but I could be mistaken) is indeed the use of #assert: or some other message to test runtime invariants. So you'd put something like: self assert: [startIndex < endIndex]. somewhere in the main code of your application, not in test code. The nice thing about using blocks is that the assertion code inside the block doesn't run if global assertions are turned off, or if (as Alexandre suggests) you temporarily override #assert: in your class to do nothing. It's this rather separate use that I was suggesting might want a different selector, and gave #run:forResult: as one possible example. Regards, -Martin _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
