Writing a unit test for a singleton implementation

[Dmitry Olshansky]

16-May-2013 01:09, Sebastian Graf пишет:
> On Wednesday, 15 May 2013 at 18:28:53 UTC, Idan Arye wrote:
>> I'm making an idioms
>> library(http://forum.dlang.org/thread/fofbrlqruxbevnxchxdp@forum.dlang.org)
>> to add to Phobos, and one of the idioms is the singleton design
>> pattern. Since I'm gonna send it to Phobos, it needs to have a unit
>> test. Here is my unit test:

[snip]

>> This unit test works - it doesn't fail, but if I remove the
>> `synchronized` from my singleton implementation it does fail.
>>
>> Now, this is my concern: I'm doing here a 500 millisecond sleep in the
>> constructor, and this sleep is required to guarantee a race condition.
>> But I'm not sure about two things:
>>
>>  - Is it enough? If a slow or busy computer runs this test, the 500ms
>> sleep of the first iteration might be over before the second iteration
>> even starts!

Sleep in concurrency code that aims to synchronize something is always 
bad idea (=BUG).

Sleep is a tool used to give up thread execution resources to avoid 
spinning on something wasting cycles. Use semaphore or analogous 
primitives to coordinate, see other posts.

>>
>>  - Is it too much? Phobos has many unit tests, and they need to be run
>> many times by many machines - is it really OK to add a 500ms delay for
>> a single item's implementation?

No.

>>
>>
>> Your opinion?
>
> tldr; don't test for races in unit tests.

One word - it's a stress test (smoke test). It should be a kind of loop 
that executes for as long as you can allow it. Days later if it didn't 
fail usually you either decide that it should be "good enough" or keep 
running them.

-- 
Dmitry Olshansky