I posted a rather long diatribe outlining why I think speed-ups
are a false goal for Lucene. Briefly, I'm convinced that as long
as the tests are run when Hudson builds Lucene, 99% of the
value of unit tests is realized. I suppose this implies that the
hard-core committers agree that as long as failed tests
are caught/corrected within a day things are fine.

Although coming from a background where unit
tests are not always required, my viewpoint may be
suspect <G>.

er...@nottobeconfusedwithhatcher.com....

On Wed, Nov 25, 2009 at 8:43 PM, Michael McCandless (JIRA)
<j...@apache.org>wrote:

>
>    [
> https://issues.apache.org/jira/browse/LUCENE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782716#action_12782716]
>
> Michael McCandless commented on LUCENE-1844:
> --------------------------------------------
>
> Will we also speed up back-compat tests?
>
> > Speed up junit tests
> > --------------------
> >
> >                 Key: LUCENE-1844
> >                 URL: https://issues.apache.org/jira/browse/LUCENE-1844
> >             Project: Lucene - Java
> >          Issue Type: Improvement
> >            Reporter: Mark Miller
> >         Attachments: FastCnstScoreQTest.patch,
> hi_junit_test_runtimes.png, LUCENE-1844.patch
> >
> >
> > As Lucene grows, so does the number of JUnit tests. This is obviously a
> good thing, but it comes with longer and longer test times. Now that we also
> run back compat tests in a standard test run, this problem is essentially
> doubled.
> > There are some ways this may get better, including running parallel
> tests. You will need the hardware to fully take advantage, but it should be
> a nice gain. There is already an issue for this, and Junit 4.6, 4.7 have the
> beginnings of something we might be able to count on soon. 4.6 was buggy,
> and 4.7 still doesn't come with nice ant integration. Parallel tests will
> come though.
> > Beyond parallel testing, I think we also need to concentrate on keeping
> our tests lean. We don't want to sacrifice coverage or quality, but I'm sure
> there is plenty of fat to skim.
> > I've started making a list of some of the longer tests - I think with
> some work we can make our tests much faster - and then with parallelization,
> I think we could see some really great gains.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-dev-h...@lucene.apache.org
>
>

Reply via email to