2014-05-02 0:18 GMT+02:00 Sven Van Caekenberghe <[email protected]>: > > On 01 May 2014, at 00:52, Nicolas Cellier < > [email protected]> wrote: > > > Hi, > > I see many usage of #should: in SciSmalltalk tests that could simply be > turned into #assert: or eventually #assert:equals: > > Why wanting to use a block? > > Other than #should:raise: and #shouldnt:raise:, I don't really see the > point of #should: alone anyway... > > IMO should: should be deprecated, less is more. > > I'm possibly the author of several of these #should: sends, so don't > take it personnally ;) > > > > P.S. or is it easier to restart the block in the Debugger? > > I cross post to pharo-dev because it's a generic question, and there are > a few #should: sends in Pharo-3.0 too. > > I also do not understand why you would want to use a block. So unless > there is a good reason to use that, a simpler API is preferable. > > BTW, and this was discussed before, #shouldnt:raise: is useless as well ;-) >
Yes, shouldnt: [...] raise: Error is completely useless because SUnit will catch the Error anyway. There are a few examples in SciSmalltalk that should be removed. Most of the time, an Error did effectively occur, so the #shouldnt:raise: tests were conceived as sort of explicit non regression test... But, the tests do not have to carry these historical bits. It's obvious that there should not be an Error raised, and the tests should rather concentrate on testing correctness of the result. I don't remember if there are a few pattern for usage of shouldnt:raise:, I was thinking for example if you want to tests an Exception handler... OK SUnit will catch any kind of Error too, but what if it is a Notification? Nicolas
