Usage of should: in tests

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Usage of should: in tests

Nicolas Cellier
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.
Reply | Threaded
Open this post in threaded view
|

Re: Usage of should: in tests

Nicolas Cellier


2014-05-01 0:52 GMT+02:00 Nicolas Cellier <[hidden email]>:
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.

--
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.
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Usage of should: in tests

Nicolas Cellier
In reply to this post by Nicolas Cellier

2014-05-02 0:18 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:

On 01 May 2014, at 00:52, Nicolas Cellier <[hidden email]> 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

--
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.
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Usage of should: in tests

Nicolas Cellier

2014-05-02 9:46 GMT+02:00 Nicolas Cellier <[hidden email]>:

2014-05-02 0:18 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:


On 01 May 2014, at 00:52, Nicolas Cellier <[hidden email]> 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

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.
Reply | Threaded
Open this post in threaded view
|

Re: Usage of should: in tests

werner kassens-2
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.
Reply | Threaded
Open this post in threaded view
|

Re: Usage of should: in tests

Nicolas Cellier

2014-05-02 12:31 GMT+02:00 werner kassens <[hidden email]>:
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


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.

--
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.
Reply | Threaded
Open this post in threaded view
|

Re: Usage of should: in tests

werner kassens-2
It may have some value for explicitely showing the bug while it exists, but this value has an expiry date.
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.
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Usage of should: in tests

Nicolas Cellier
In reply to this post by Nicolas Cellier



2014-05-02 10:16 GMT+02:00 Henrik Johansen <[hidden email]>:

On 01 May 2014, at 12:52 , Nicolas Cellier <[hidden email]> 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.

Reading code with should:, I always imagined a trailing question mark...

self should: [IHaveIceCreamForLunch] ?

And even more so with should:raise:

self should [thisPieceOfCode] raise: SomeError ?

I dunno, you tell me!

The potentially constructive suggestion out of that, is that, at least to me,
assert:raises: deny:raises: sound more natural than assert:raise: when read out loud.


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,
Henry

--
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.