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 <G>....... 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 found. 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>. Best Erick On Wed, Nov 25, 2009 at 5:07 PM, Michael McCandless < luc...@mikemccandless.com> 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 <u...@thetaphi.de> 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: 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 > >
