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. You received this message because you are subscribed to the Google Groups "SciSmalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Some not so different opinion: http://joachimtuchel.wordpress.com/2011/09/15/sunit-and-shouldshouldnt-vs-assertdeny/ 2014-05-01 0:52 GMT+02:00 Nicolas Cellier <[hidden email]>:
You received this message because you are subscribed to the Google Groups "SciSmalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
In reply to this post by Nicolas Cellier
2014-05-02 0:18 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:
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 You received this message because you are subscribed to the Google Groups "SciSmalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
2014-05-02 9:46 GMT+02:00 Nicolas Cellier <[hidden email]>: Ah, here is a pattern that looks completely correct to me:
testIfNil | object block | object := ProtoObject new. self shouldnt: [ object ifNil: [ self halt ]] raise: Halt. self assert: (object ifNil: [ nil ]) == object. "Now the same without inlining." block := [ self halt ]. self shouldnt: [ object ifNil: block ] raise: Halt. block := [ nil ]. self assert: (object ifNil: block) == object. You received this message because you are subscribed to the Google Groups "SciSmalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
In reply to this post by Nicolas Cellier
Hi Nicolas,
-- for me should is linked in my mind to error-checking, hence i never use #should:. i do use #shouldnt:raise: extensively for bug documentation though: if you correct a bug no error will be thrown in the test, but with #shouldnt:raise: i document that before the correction this wouldnt work. werner You received this message because you are subscribed to the Google Groups "SciSmalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
2014-05-02 12:31 GMT+02:00 werner kassens <[hidden email]>:
Exactly, I often used it in mantis reports too.! That's what I called historical bits. It may have some value for explicitely showing the bug while it exists, but this value has an expiry date. But once the bug is fixed, it only documents that once upon a time, there was a bug in this part of code, then what? For non regression, and documentation, testing self assert: someExpression = expectedResult is well enough.
You received this message because you are subscribed to the Google Groups "SciSmalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
i generally agree of course, but dhb is insofar a special case, as it does not really have an expiry date in my mind: the bug tests explain, why the code of the book was changed, and this could interest someone who reads the book. werner You received this message because you are subscribed to the Google Groups "SciSmalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
In reply to this post by Nicolas Cellier
2014-05-02 10:16 GMT+02:00 Henrik Johansen <[hidden email]>:
The potentially constructive suggestion out of that, is that, at least to me, I see, an affirmative form could be: [thisPieceOfCode] shouldRaise: SomeError but we need to insert the testimony of SUnit... assert:raises: is exactly that, and makes sense Cheers, You received this message because you are subscribed to the Google Groups "SciSmalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Free forum by Nabble | Edit this page |