db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Monitoring/improving code coverage (was Re: code coverage results for trunk - svn revision no 390306)
Date Mon, 03 Apr 2006 23:13:10 GMT
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.


View raw message