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
