Hi,
Code coverage:
I value code coverage as part of the review and development process. As
a project wide target I think it's not as high value, but having a
standard encourages people to take the time to use the tools and that's
a healthy side effect. Code coverage is a measure of code
If the code coverage goes down or do not go above the required cutoff due
to adding toString or getter setter like functionality, can we make it a
process to explain the reason in the JIRA before committing it?
Regarding changes in hard to unit tests parts of the code, can we make it a
process to
re: code coverage (this could become it's own thread, and probably should)
As somebody working on a new large feature (CASSANDRA-8457), I have a few
thoughts/observations about code coverage. As a preface, though, I'll point
out that we have jacoco (http://www.jacoco.org/jacoco/trunk/index.html)
How do we plan on verifying #4? Also, root-cause to tie back new code that
introduces flaky tests (i.e. passes on commit, fails 5% of the time
thereafter) is a non-trivial pursuit (thinking #2 here), and a pretty
common problem in this environment.
On Mon, Mar 27, 2017 at 6:51 PM, Nate McCall
I don't want to lose track of the original idea from François, so
let's do this formally in preparation for a vote. Having this all in
place will make transition to new testing infrastructure more
goal-oriented and keep us more focused moving forward.
Does anybody have specific
