On Mon, Jan 18, 2010 at 2:36 PM, Drew Farris <drew.far...@gmail.com> wrote: > I'm suggesting that the instantiator/caller of the class choose > between a regular and test-friendly RNG. In some classes that creator > will be a unit test in other cases the creator will be another piece > of production code. In some cases the decision as to which type of RNG > to use will need to be made further up the object graph than the > immediate instantiator/caller, and generally it should be made as > close to main() or setUp() as possible.
Yes, but the problem is the production code. The test code knows it's in test mode. The production code does not, since it's executed in test and non-test mode. It can't make this choice independently. You can punt the choice all the way up to fix that. Then regular callers are forced to instantiate and supply the RNG in all cases, and the API has Randoms all over the place, and I suppose I don't quite like that aesthetically. > RandomUtils essentially achieves the same thing in a static fashion. > The class itself decides that it will always delegate to RandomUtils > and random utils provides the different strategies. Currently if > RandomUtils.useTestSeed() is called once in a VM all other callers of > RandomUtils.getRandom() will get a test seed. ... yep and I think this is cleaner than the option above. That may be the only delta between what we're saying. (Separately I'd like to hijack MAHOUT-260 now to talk about the still-existing repeatability problem, which is a different question. Any thoughts on that? it patches this up pretty well but isn't entirely pretty.)
