lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <...@thetaphi.de>
Subject RE: failure in TestTrieRangeQuery
Date Wed, 04 Feb 2009 10:44:15 GMT
Hi,

> > : By allowing Random to randomly seed itself, we effectively test a
> > much
> > : much larger space, ie every time we all run the test, it's
> > different.  We can
> > : potentially cast a much larger net than a fixed seed.
> >
> > i guess i'm just in favor of less randomness and more iterations.
> >
> > : Fixing the bug is the "easy" part; discovering a bug is present is
> > where
> > : we need all the help we can get ;)
> >
> > yes, but knowing a bug is there w/o having any idea what it is or
> > how to
> > trigger it can be very frustrating.
> 
> I agree, it's frustrating.  But I'd prefer to know the bug is there
> and then
> writhe in frustration at not being able to reproduce it very easily,
> then let
> the bug go undetected.  I guess ignorance is not bliss, for me ;)
> 
> > it would be enough for tests to pick a random number, log it, and
> > then use
> > it as the seed ... that way if you get a failure you at least know
> > what
> > seed was used and you can then hardcode it temporarily to reproduce/
> > debug
> 
> +1!  I like this approach.  We could record the seed up front, and
> then in
>   a try/finally if the test failed, print the seed.

I implemented this for TestTrieRangeQuery (see patch). I catch
java.lang.Error and print the random seed recorded before (The seed is
generated by a static Random instance for each test method in separate:
Because you cannot predict the order of tests, each test method should have
its own Random instance). As both the Java 1.4 AssertionError and the jUnit
AssertionFailedError are subclasses of Error, they can be catched and
rethrown easily.

Uwe

Mime
View raw message