On 02/20/2010 05:45 PM, Michael McCandless 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?
+1
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
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
