Ted, It depends on the test implementation itself. Generally, I believe the pattern that is followed is:
RandomUtils.useTestSeed(); Random r = RandomUtils.getRandom(); The potential issue I see is if any tests expected to run using a seed >other< than the test seed. Now that we are no longer forking, calling RandomUtils.useTestSeed() in test A will cause the test seed to be used in B, C, D, E etc. In this case it makes sense to avoid using a stateful static classes like RandomUtils, probably to condense this down to RandomUtils.getTestRandom(). RandomUtils.getRandom() will reset the seed in any case, to a default seed if useTestSeed() as ever been called, to something random if useTestSeed() has never been called. On Sun, Jan 17, 2010 at 8:39 PM, Ted Dunning <ted.dunn...@gmail.com> wrote: > Do the RandomUtils reset the seed for every test as desired? > > On Sun, Jan 17, 2010 at 5:38 PM, Drew Farris <drew.far...@gmail.com> wrote: > >> On Sun, Jan 17, 2010 at 2:55 PM, Sean Owen <sro...@gmail.com> wrote: >> > Am I right that running tests in 1 JVM instead of n JVMs helps >> > mitigate this? because I just committed that change. >> > >> >> I just updated to HEAD, and this seems to have fixed the problem. Unit >> tests are completing in times in-line with those reported by the tests >> themselves. >> >> Since this was happening at class loading time, running all of the >> tests in a single VM does mitigate this becuase less forks mean less >> entropy drain and there is more time to collect entropy between forks. >> > > > > -- > Ted Dunning, CTO > DeepDyve >
