Comments on: Testing Anti-Patterns: Incidental Coverage http://jasonrudolph.com/blog/2008/06/17/testing-anti-patterns-incidental-coverage/ puts Blog.new("nonsense") Thu, 04 Dec 2008 22:44:45 +0000 http://wordpress.org/?v=2.6.3 By: Mark Wilden http://jasonrudolph.com/blog/2008/06/17/testing-anti-patterns-incidental-coverage/#comment-14369 Mark Wilden Wed, 18 Jun 2008 23:59:39 +0000 http://jasonrudolph.com/blog/?p=176#comment-14369 <p>100% doesn't prove that you've written all the tests you need. But less than 100% (usually) proves that you haven't.</p> <p>///ark</p> 100% doesn’t prove that you’ve written all the tests you need. But less than 100% (usually) proves that you haven’t.

///ark

]]> By: Bryan Cook http://jasonrudolph.com/blog/2008/06/17/testing-anti-patterns-incidental-coverage/#comment-14366 Bryan Cook Wed, 18 Jun 2008 04:06:16 +0000 http://jasonrudolph.com/blog/?p=176#comment-14366 <p>Totally agree, and love the term "incidental coverage" -- coverage can't be used as a confidence gauge if the tests don't provide value. I wrote a similar post a few weeks ago about <a href="http://stupiddumbguy.blogspot.com/2008/05/tdd-tips-getting-value-out-of-code.html" rel="nofollow">tips for using code coverage.</a></p> Totally agree, and love the term “incidental coverage” — coverage can’t be used as a confidence gauge if the tests don’t provide value. I wrote a similar post a few weeks ago about tips for using code coverage.

]]> By: Mark Levison http://jasonrudolph.com/blog/2008/06/17/testing-anti-patterns-incidental-coverage/#comment-14365 Mark Levison Tue, 17 Jun 2008 21:32:54 +0000 http://jasonrudolph.com/blog/?p=176#comment-14365 <p>While I hate to sound like a TDD fanatic - because I'm not, I want to suggest that the focus on code coverage betrays another issue. As I see it improving the quality of code is a side effect of TDD not the primary benefit. The real benefit is being more productive and being forced to write less code. Once you do TDD (and I fall off the band wagon frequently enough) you can stop thinking about code coverage after you wrote the code test first. So the majority of the code is well tested. Code coverage is useful in a legacy situation where you're trying to decide where the biggest problems lie (another with class/file size and complexity measures etc.)</p> While I hate to sound like a TDD fanatic - because I’m not, I want to suggest that the focus on code coverage betrays another issue. As I see it improving the quality of code is a side effect of TDD not the primary benefit. The real benefit is being more productive and being forced to write less code. Once you do TDD (and I fall off the band wagon frequently enough) you can stop thinking about code coverage after you wrote the code test first. So the majority of the code is well tested. Code coverage is useful in a legacy situation where you’re trying to decide where the biggest problems lie (another with class/file size and complexity measures etc.)

]]> By: Anders Bengtsson http://jasonrudolph.com/blog/2008/06/17/testing-anti-patterns-incidental-coverage/#comment-14364 Anders Bengtsson Tue, 17 Jun 2008 13:19:10 +0000 http://jasonrudolph.com/blog/?p=176#comment-14364 <p>The irony is that very low code quality can easily get higher coverage than good code. As I've added tests to legacy code, I've often found that it will run lots of unrelated code and get a high global coverage count. It probably doesn't even make sense to compare the coverage numbers from legacy code with retro-fitted tests to numbers from test-driven code. It just doesn't mean the same thing.</p> The irony is that very low code quality can easily get higher coverage than good code. As I’ve added tests to legacy code, I’ve often found that it will run lots of unrelated code and get a high global coverage count. It probably doesn’t even make sense to compare the coverage numbers from legacy code with retro-fitted tests to numbers from test-driven code. It just doesn’t mean the same thing.

]]>