lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <>
Subject Re: (LUCENE-1844) Speed up junit tests
Date Thu, 26 Nov 2009 01:29:38 GMT
IMHO there are other reasons to upgrade to junit4 besides
parallelization, there are some nice new capabilities. I
suppose the analogous question is "why upgrade to
Lucene 2.9?"

Especially since it's not a matter of upgrading. Junit3 tests run
just fine under junit4. I've tested after removing the
junit3 jar from lib, no problem. It even seems to run
slightly faster, which makes me wonder...

So really, we have the best of both worlds. No work involved in
using Junit4 with the current tests, but the ability to use the
new features of Junit4. Although I'm sure there'll be
*something* that bites us, I have great faith in Murphy.

Kinda reminds me of the Lucene drop-in replacement policy

But on the topic of parallelization: I'm not at all sure
it's worth the effort. As far as I can tell, it really only gets significant
gains when you have more cores to run with. It's not at all clear
to me how much time we spend doing I/O in the tests... very little
I suspect (although I confess I don't know for sure). And if we're
CPU bound anyway, parallelization doesn't help. Anybody know
for sure?

And say we did all the work to parallelize all the tests. And say that
instead of taking 25 minutes on my 3 year old MacBook Pro, we
got it down to 10 minutes. Who cares? 10 minutes is still too long
according to the eXtreme Programming (XP) folks, and I sympathize
with their point of view. Even though I did  spend some time trying
to trim some time.

The XP approach to unit testing is to run it almost every time you
change a line of code. OK, I'm exaggerating, but not by too
much with the die-hard XP folks. Even at 10 minutes, we can't
do that.

So,  I think the value for Lucene/SOLR comes *not* from running the
tests 15 times an hour. I think the real value comes from not
letting errors hide for days/weeks/months/releases. So I'm quite willing
to let the automated builds catch the unit test failures in unexpected
places in those instances where I don't run all of the tests before
a patch is committed. As long as we fix them as soon as they're

OK, I'm rambling. I'm off for Thanksgiving, and my daughter is
at her in-laws until tomorrow (they're visiting from CA). So sue
me <G>.


On Wed, Nov 25, 2009 at 5:07 PM, Michael McCandless <> wrote:

> Is the only reason to upgrade to junit 4, to get the parallelization
> possibility (which isn't sounding very compelling!)?
> Ie, making our unit tests lean is fully independent of junit 4?
> Mike
> On Wed, Nov 25, 2009 at 4:17 PM, Uwe Schindler <> wrote:
> >> junit 4 parallelization is still in its infancy. I think the docs for it
> >> are just in the changes file that it was first released with. That
> >> version had severe bugs that made it almost unusable - I think thats
> >> mostly fixed in a newer release. There is also a much better impl of one
> >> of the key classes (I think they call it computer) written by someone
> >> else that will eventually go into the code base I think (written by the
> >> guy(s) that I think found/fixed the initial buggy-ness) - essentially, I
> >> think its still unbaked.
> >
> > There is another problem. Parallelization would only work with tests,
> that
> > do not change gloabl defaults. E.g. LocalizedTestCase changes the default
> > locale. If another test would run in Paralale, it would break.
> >
> > Son only isolated tests can run in parallel. This LocalizedTestCase
> cannot
> > solved in another way. The same would have been in 2.9 with the
> > TokenStream.useOnlyNewAPI switch, but this is now longer the case for
> 3.1.
> >
> > Uwe
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message