A little update on sUnit and should:/shouldnt:


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 should: and 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 assert: .

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.