I still think there's value to faster tests, even if they don't become so fast as to enable "fully interactive testing".
Plus, this is an ongoing goal with time, not a one-time event. As we create tests we should generally try to maximize coverage and minimize CPU cost, as long as the effort is smallish. Mike On Wed, Nov 25, 2009 at 9:32 PM, Erick Erickson <erickerick...@gmail.com> wrote: > 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 >> >> > > 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 >> > > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
