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:
I agree this is more concise, there is no reference to "self" to formulate the assertion. Having to use "self" in "self assert:" has more to do with an unnecessary convention than bringing a real value. In that case, disabling assertion has to be done by modifying BlockClosure>>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.
The method assert:equals: should accept a block in my opinion. TestCase>>assert:equals: may be rewritten as: assert: expectedAsBlockOrValue equals: actualAsBlockOrValue | v1 v2 | v1 := expectedAsBlockOrValue value. v2 := actualAsBlockOrValue value. ^ self assert: (v1 = v2) description: (self comparingStringBetween: v1 and: v2)
* Object assert: accepts a boolean or a block. I don't know of any standard for this.
No standard as far as I know
* BlockClosure>>assert does not take any arguments, so I feel it is very clean.
But you need to modify it to cancel runtime checks
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:.
assert:equals: could also be updated. Some test units in the image use [] as arguments to assert: and deny:. StringTest is one of them.
Object>>assert: should be removed/deprecated in favor of BlockClosure>>assert. This removes confusion with TestCase>>assert:.
Ideally, this is valuable. However, there is a number of tests that use Object>>assert: (and not only my code :-). ZipEncoderTree is an example
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.
#assertWithDescription: is useful yes. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.