Alexandre Bergel wrote: >> 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: > [...] > > This is exactly what I had in mind > I regularly use assert: to describe invariant, pre and postcondition. > This complement testing pretty well in my opinion.
Agreed. I prefer, though, to use BlockClosure>>assert, so usage becomes something like: [2 + 2 = 5] assert. I see that this is already implemented, based on Object>>assert: There are inconsistencies that bother me. * TestCase>>assert: in most Smalltalks accepts only a boolean. In Pharo, it accepts either a boolean or a block. This makes tests less portable. * TestCase>>assert:equals: (a very useful method) does not accept a block. Anyone used to giving blocks to #assert: would probably expect this method to accept a block. * Object assert: accepts a boolean or a block. I don't know of any standard for this. * BlockClosure>>assert does not take any arguments, so I feel it is very clean. Proposed changes: (based on earlier discussion plus personal opinion) TestCase>>assert: should only accept a boolean. This brings compatibility with other Smalltalks, and consistency with TestCase>>assert:equals:. Object>>assert: should be removed/deprecated in favor of BlockClosure>>assert. This removes confusion with TestCase>>assert:. Object>>assert:description: and Object>>assert:descriptionBlock: should be removed/deprecated in favor of (new) BlockClosure>>assertWithDescription:, which accepts either a block or a string. This provides convenient invariant and pre/post condition testing. Opinions? -Martin _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
