Fully Covered for Quality

In pursuit of code quality: Don't be fooled by the coverage report "I'll say it one more time: you can (and should) use test coverage tools as part of your testing process, but don't be fooled by the coverage report. The main thing to understand about coverage reports is that they're best used to expose code that hasn't been adequately tested. When you examine a coverage report, seek out the low values and understand why that particular code hasn't been tested fully. Knowing this, developers, managers, and QA professionals can use test coverage tools where they really count -- namely for three common scenarios:

* Estimating the time to modify existing code
* Evaluating code quality
* Assessing functional testing"

Also a previous article, Measure test coverage with Cobertura ""The general philosophy is this: if it can't break on its own, it's too simple to break. First example is the getX() method. Suppose the getX() method only answers the value of an instance variable. In that case, getX() cannot break unless either the compiler or the interpreter is also broken. For that reason, don't test getX(); there is no benefit. The same is true of the setX() method, although if your setX() method does any parameter validation or has any side effects, you likely need to test it."

I don't agree. I've lost count of the number of bugs I've found in code that was "too simple to break." It's true that some getters and setters are so trivial that there's no way they can fail."

"In theory, there's no guarantee that writing tests for uncovered code will reveal bugs. In practice, I've never seen it fail to find them. Untested code is full of bugs. The fewer tests you have, the more undiscovered bugs lurk in your code."

Both talk about a free code coverage tool, Cobertura.

A recent thread on the AJUG QLD list.