Writing a unit test for a singleton implementation
Diggory
diggsey at googlemail.com
Wed May 15 12:17:22 PDT 2013
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?
There's no real way to reliably test race conditions. One thing
you could do is get a bunch of threads ready and waiting to
access "Foo.instance" and then notify them all at once, that way
you can do away with "sleep" which is not great to have in a unit
test anyway. Repeat this a few times and it should be fairly
reliable, plus it will usually be much faster because you don't
have to sleep.
More information about the Digitalmars-d
mailing list