db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1116) Define a minimal acceptance test suite for checkins
Date Fri, 17 Mar 2006 01:34:02 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1116?page=comments#action_12370770 ] 

Rick Hillegas commented on DERBY-1116:
--------------------------------------

Our regression tests clearly take too long. For the record, I think that 1 hour is a reasonable
amount of time for a mats suite to churn. To date, several suggestions have been made for
reducing the churn. I'm listing them from (off the top of my head) least to most expensive:

1) Fix the test harness so that it doesn't create a new database and bounce the server for
every test.

2) Better parameterize the tests so that you could parallelize test runs.

3) Prune back the existing suites. I'm more or less clear about how you identify victims:
e.g., tests which routinely generate false negatives, including the luckless tests which always
flunk the tinderbox. I'm also reasonably certain that we could identify a handful of really
good tests, the super-sensitive canaries in the mine shaft. Other than that, there is a huge
mass of middling tests and I'm not clear on how you sift out the winners.

4) Start converting tests to JUnit to eliminate the drag of writing test chatter to disk.
Dan's experiments with JUnit seemed to show some promise here. 

> Define a minimal acceptance test suite for checkins
> ---------------------------------------------------
>
>          Key: DERBY-1116
>          URL: http://issues.apache.org/jira/browse/DERBY-1116
>      Project: Derby
>         Type: Improvement
>   Components: Test
>     Reporter: David Van Couvering
>     Priority: Minor

>
> Now that we have an excellent notification system for tinderbox/nightly regression failures,
I would like to suggest that we reduce the size of the test suite being run prior to checkin.
  I am not sure what should be in such a minimal test, but in particular I would like to remove
things such as the stress test and generally reduce the number of tests being run for each
subsystem/area of code.
> As an example of how derbyall currently affects my productivity, I was running derbyall
on my machine starting at 2pm, and by evening it was still running.  At 9pm my machine was
accidentally powered down, and this morning I am restarting the test run.
> I have been tempted (and acted on such temptation) in the past to run a smaller set of
tests, only to find out that I have blocked others who are running derbyall prior to checkin.
 For this reason, we need to define a minimal acceptance test (MATS) that we all agree to
run prior to checkin.
> One could argue that you can run your tests on another machine and thus reduce productivity,
but we can't assume everybody in the community has nice big test servers to run their tests
on.
> If there are no objections, I can take a first pass at defining what this test suite
should look like, but I suspect many others in the community have strong opinions about this
and may even wish to volunteer to do this definition themselves (for example, some of you
who may be working in the QA division in some of our Big Companies :) ).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message