On Sun, Jan 17, 2010 at 9:10 PM, Sean Owen <sro...@gmail.com> wrote: > There are already cases where code needs to control the seed (mostly > to serialize/deserialize the exact state of an object). I don't think > that's the issue per se? The issue is when an RNG lives beyond one > test, and there are legitimate reasons that may be so.
Ahh, ok, I wasn't really considering this. Would it be sufficient to assign the RNG to a static field in the test class in this case? If it needed to live across multiple classes, it could be public. Nevertheless.. > I don't see how a getTestRandom() method fixes something... I can't > call this in my non-test code, and then tests can't control those > RNGs. The non-test code can't make this decision which is why they > don't. I don't think this is the problem/solution but rather having a > way to globally reset all RNGs. I suspect I'm missing something here because I don't understand how randomness is used in the non-test code or specifically how the RNG's are managed. I was (falsely, likely) assuming that the non-test code didn't obtain the RNG itself but rather had it provided/injected by an external source. In the context of a test, something from getTestRandom() which uses a fixed seed could be injected, while in production code something else would be.
