On Mon, Jan 18, 2010 at 9:06 AM, Sean Owen <sro...@gmail.com> wrote: > (Separately you could argue we're going about this all wrong, by > trying to depend on the exact output of the RNG..
No argument here. In practice I don't think we can really get around using a pre-seeded RNG for tests. > You've moved around the injection, but nothing else I think. Am I > misunderstanding because that seems to be why I'm not following > getTestRandom(). You get it entirelym Moving around the injection in this case produces more testable code in that you don't have a class-defined behavior for the RNG. Instead it becomes an externally-defined behavior. > (Taking it as a constructor param is the conventional way to set up > for injecting, but from an API perspective I don't quite like it. I > understand why an evaluator necessarily needs a Recommender to exist, > but why do I need to give it a Random, conceptually?) It really depends on the evaluator implementation. In the case of GenericRecommenderIRStatsEvaluator the evaluator happens use randomness to perform the evaluation function. I agree that these sorts of injections should not be accommodated at the interface level and shouldn't pollute the API. Drew
