We have some NUnit cross-system test assemblies that run in parallel. They upload files and watch to see how they are processed. We were inserting a randomly generated value into the filenames in an attempt to avoid identically named files overwriting each other.
Unfortunately, this didn’t work, and we saw frequent test failures. In particular, we found that filenames generated by one test assembly were often identical to those generated by another.
I wanted to understand why this was happening, so I did some investigation.
We were getting our values fromTestContext.CurrentContext.Random, which is an instance of NUnit’s Randomizer class.
When we look at the implementation of Randomizer, we see this:
static Randomizer()
{
InitialSeed = new Random().Next();
Randomizers = new Dictionary<MemberInfo, Randomizer>();
}
The Randomizer is statically seeded with a value generated by the System.Random class. Because this seed is static, the same sequence of random values is shared by all references to Randomizer within each assembly, producing a sequence of values that are highly likely to be different from each other. However, references to Randomizer in a concurrently running assembly use a different instance and have their own sequence of values with its own seed.
Let’s have a quick look at how System.Random is seeded.
The MSDN documentation tells us:
- The Random() constructor uses the system clock to provide a seed value. This is the most common way of instantiating the random number generator.
And goes on to warn:
…because the clock has finite resolution, using the parameterless constructor to create different Random objects in close succession creates random number generators that produce identical sequences of random numbers.
It would seem that our two parallel test assemblies often start executing within such a short interval of each other, and that NUnit’s Randomizer is seeded with the same value in each assembly, which means the sequences of values are identical.
There is some discussion of introducing a mechanism for controlling the seeding of Randomizer in NUnit, but in the mean time, the solution to our problem was to seed our own System.Random instances, rather than relying on NUnit’s.
Matthew Butt 