A few days after my post sUnit and should:/shouldnt: vs. assert:/deny: I received a mail from Niall Ross who maintains sUnit. I was quite busy the last weeks, so I am a bit late with this update…
Niall pointed out that
shouldnt: both are deprecated, so it is not a good idea to use them anyways. If I had taken a closer look at the category names in
TestCase, I could have found out myself.
He also confirmed that the current behaviour of
shouldnt:raise: is a bug. We still have to work out if the method should fail if the Block raises another exception than the one mentioned or if this means the test is passed. I think
shouldnt:raise: is really meant to say: throw whatever exception you like, as long as it’s not the one(s) I name here! I’m planning to try and fix this one this week if I find the time and nerve.
Along with Niall, quite a few people made a strong point about my suggestion to make sUnit accept Blocks as a parameter to
I’m not sure it buys anything to make assert: take a block. When not checking for the raising or non-raising of errors, why use a block? (By all means give me counterexamples).
Even stronger opinions have been expressed about my suggestion to do this by implementing the value method on Object. I tend to not agree to most of them, but it was again Niall who came up with the strongest argument: as long as
Object>>value is not standard on all Smalltalk implementations, sUnit shouldn’t introduce it. I must admit I agree to this one. Porting code from one Smalltalk dialect to another can be hard without this one, and even if implementing
Object>>value is not much of a deal, it should be avoided.
So I am now happy to write
self assert: (myBlock value = true).
in my future tests.
This is probably necessary in most cases anyways, because the Blocks we use most often do not evaluate to a Boolean. So checking their result in an assert: rather than in a (deprecated) should: is the way to go.
Thanks to all commenters and to Niall for taking time to think about my post and comment.