On 4/8/13 5:05 PM, "Dawid Weiss" <dawid.we...@cs.put.poznan.pl> wrote:
>> thought I checked for that but apparently I got confused. I do find it >> disconcerting that the random seed can get incremented by >> LuceneTestCase.newDirectory() a different number of times depending on >> wether or not -Dtests.seed has been set. > >It's not really like that. By passing -Dtests.seed you're not "just" >incrementing/ changing the random generator. You're starting from a >different seed so you're running a whole different execution scenario. >Think of it as Heisenberg's uncertainty principle -- if you've touched >something on the lab plate (anything) then the outcome will be >different. > >If you want your test to pick a random directory but make this choice >insensitive to tests.seed then use the newDirectory(Random) method >with a "forked" random number generator. As in here: > >Random forkedRandom = new Random(random().nextLong()); >Directory myDirectory = LuceneTestCase.newDirectory(forkedRandom); > >then you can change "myDirectory" to your liking and it won't affect >the default random generator... > >Random forkedRandom = new Random(random().nextLong()); >// you don't even need to call newDirectory(forkedRandom) but I'll keep >it here. >Directory myDirectory = LuceneTestCase.newDirectory(forkedRandom); >// temporarily substitute with something else... >myDirectory = ...; I understand what you're saying and how it works today, and it isn't really surprising in hindsight. Of course I could use my own random but then if I do so, I forgo all the convenience code in LuceneTestCase that depend on random(), and you can't really blame me for using those nice convenience methods. The specific circumstance in which I set -Dtests.directory is that I wanted to use SimpleFSDirectory so that I could also use SimpleTextCodec so that I could inspect what Lucene was storing. Boom, I did this and my whole test is testing something different than what I wanted to. Your suggestion is that I modify my tests, which are already using extensive randomization, to not use all the convenience methods, I'm using. Sure it's possible but... :-( Again, the status quo is not surprising (in hindsight), it's not a bug or deficiency (I rescind my use of the word "disconcerting"), but it would be nice if it was easier for me to pick different Lucene infrastructure components via system properties without affecting the random state. One potential way to accomplish the goal that would be less jarring to the existing code is to have LuceneTestCase's convenience methods use a different random() -- say internalRandom() that is based off of a copy of random() initialized at the start of the test. Just an idea. ~ David --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
