Writing a unit test for a singleton implementation

[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:
>
>     static class Foo
>     {
>         mixin LowLockSingleton;
>
>         this()
>         {
>             Thread.sleep(dur!"msecs"(500));
>         }
>     }
>
>     Foo[10] foos;
>
>     foreach(i; parallel(iota(foos.length)))
>     {
>         foos[i] = Foo.instance;
>     }
>
>     foreach(i; 1 .. foos.length)
>     {
>         assert(foos[0] == foos[i]);
>     }
>
>
> 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!
>
>  - 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?
>
>
> Your opinion?

Also note that unit tests are supposed to run fast (definitely < 
50 ms), because running 500-5000 of them should be relatively 
cheap. Apart from that, races aren't something to test for in a 
unit test. It may be more a kind of integration test, though the 
sporadic nature of races makes them candidates for "One of those 
occasionally failing bad guys hamstringing development... Let's 
just ignore him."-type thinking.
I would create a seperate Test suite for race tests and execute 
them multiple times if need be... But there are a million better 
sources on the internet than me on that topic.

tldr; don't test for races in unit tests.