ok, can do. if it turns out there is a problem, we can revert until some work has been done on the tests.
On Sat, Feb 20, 2010 at 5:45 PM, Michael McCandless < luc...@mikemccandless.com> wrote: > Currently the tests run 1 jvm per test suite (eg, TestIndexWriter has > its own jvm), I believe, and we haven't seen test failures... so I > think for the most part tests are not interfering with each other > (messing up global state). > > It should be less likely that we see interactions across test suites > (but obviously still possible). > > I think we should commit this and then if there are somehow problems > we can address them, then? > > Mike > > On Sun, Feb 14, 2010 at 6:27 AM, Robert Muir <rcm...@gmail.com> wrote: > > its not just statics, I think we should really look at ensuring files are > > closed etc, or eventually there will be a problem! > > > > I guess in general the tradeoff is, it requires us to have better test > code. > > > > On Sun, Feb 14, 2010 at 5:53 AM, Uwe Schindler <u...@thetaphi.de> wrote: > >> > >> At least we should check all core tests to not set any static defaults > >> without try...finally! Are there any possibilities inside > Eclipse/other-IDEs > >> to check this? > >> > >> Uwe > >> > >> ----- > >> Uwe Schindler > >> H.-H.-Meier-Allee 63, D-28213 Bremen > >> http://www.thetaphi.de > >> eMail: u...@thetaphi.de > >> > >> > -----Original Message----- > >> > From: Michael McCandless [mailto:luc...@mikemccandless.com] > >> > Sent: Sunday, February 14, 2010 11:43 AM > >> > To: java-dev@lucene.apache.org > >> > Subject: Re: (LUCENE-1844) Speed up junit tests > >> > > >> > Wow -- this is MUCH faster! I think we should switch... > >> > > >> > It seems like we use a batchtest for all core tests, then for all > >> > back-compat tests, then once per contrib package? Ie, so "ant > >> > test-core" uses one jvm? > >> > > >> > I think we should simply fix any badly behaved tests (that don't > >> > restore statics). It's impressive we already have no test failures > >> > when we do this... I guess our tests are already cleaning things up > >> > (though also probably not often changing global state, or, changing it > >> > in a way that'd lead other tests to fail). > >> > > >> > Mike > >> > > >> > On Sat, Feb 13, 2010 at 5:23 PM, Robert Muir <rcm...@gmail.com> > wrote: > >> > > On Fri, Nov 27, 2009 at 1:27 PM, Michael McCandless > >> > > <luc...@mikemccandless.com> wrote: > >> > >> > >> > >> Also one thing I'd love to try is NOT forking the JVM for each test > >> > >> (fork="no" in the junit task). I wonder how much time that'd > buy... > >> > >> > >> > > > >> > > it shaves off a good deal of time on my machine. > >> > > > >> > > 'ant test-core': 4 minutes, 39 seconds -> 3 minutes, 3 seconds > >> > > 'ant test': 11 minutes, 8 seconds -> 7 minutes, 13 seconds > >> > > > >> > > however, it makes me a little nervous because i'm not sure all the > >> > tests > >> > > cleanup nicely if they change statics and stuff. > >> > > anyway, here's the trivial patch (you don't want fork=no, because it > >> > turns > >> > > off assertions) > >> > > > >> > > Index: common-build.xml > >> > > =================================================================== > >> > > --- common-build.xml (revision 909395) > >> > > +++ common-build.xml (working copy) > >> > > @@ -398,7 +398,7 @@ > >> > > </condition> > >> > > <mkdir dir="@{junit.output.dir}"/> > >> > > <junit printsummary="off" haltonfailure="no" > >> > maxmemory="512M" > >> > > - errorProperty="tests.failed" > >> > failureProperty="tests.failed"> > >> > > + errorProperty="tests.failed" > >> > failureProperty="tests.failed" > >> > > forkmode="perBatch"> > >> > > <classpath refid="@{junit.classpath}"/> > >> > > <assertions> > >> > > <enable package="org.apache.lucene"/> > >> > > > >> > > -- > >> > > Robert Muir > >> > > rcm...@gmail.com > >> > > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > >> > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: java-dev-h...@lucene.apache.org > >> > > > > > > > > -- > > Robert Muir > > rcm...@gmail.com > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > -- Robert Muir rcm...@gmail.com
