db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Monitoring/improving code coverage (was Re: code coverage results for trunk - svn revision no 390306)
Date Mon, 03 Apr 2006 23:24:34 GMT
Backing out the code was a suggestion, not a rule.  What is appropriate 
I think depends upon the situation.

My main point is it would be good to have the information made available 
to us in a timely and "in-your-face" way -- we don't have to go 
searching for it, and we find out right away -- so we can discuss it as 
a community and try to make the right decision.


Daniel John Debrunner wrote:
> David W. Van Couvering wrote:
>>I think the same could be done for code coverage regressions.  If a new
>>chunk of code is checked in and the numbers drop way way down for a
>>given module, I think that is cause for concern and a committer could
>>reasonably insist that the feature is not sufficiently tested and back
>>out the change, or at least block any future checkins in that area until
>>enough tests are provided.
> So we could have applied this rule to JDBC 4.0 checkins. JDBC 4.0 code
> was checked in, the code coverage numbers decreased and could not
> increase until the tests could run under JDBC 4.0.
> In this case requiring the JDBC 4.0 changes be backed out until all the
> tests ran under JBDC 4.0 seems too drastic. Goes against the model of
> incremental development.
> Dan.

View raw message