coverage.py: "Statement coverage is the weakest measure of code coverage"

[Ben Finney]

John Roth <JohnRoth1 at jhrothjr.com> writes:

> On Oct 28, 4:56 pm, Ben Finney <b... at benfinney.id.au> wrote:
> > What approach could we take to improve 'coverage.py' such that it
> > *can* instrument and report on all branches within the written
> > code module, including those hidden inside multi-part statements?
> 
> If I was going to do it, I'd start by recognizing that Python
> doesn't have hooks where I need them, and it doesn't have a byte
> code dedicated to a debugging hook (I think).

Is this something that Python could be improved by adding? Perhaps
there's a PEP in this.

> One last little snark: how many of us keep our statement coverage
> above 95%? Statement coverage may be the weakest form of coverage,
> but it's also the simplest to handle.

Yes, I have several projects where statement coverage of unit tests is
98% or above. The initial shock of running 'coverage.py' is in seeing
just how low one's coverage actually is; but it helpfully points out
the exact line numbers of the statements that were not tested.

Once you're actually measuring coverage as part of the development
process (e.g. set up a rule so 'make coverage' does it automatically),
it's pretty easy to see the holes in coverage and either write the
missing unit tests or (even better) refactor the code so the redundant
statements aren't there at all.

-- 
 \     "I'd like to see a nude opera, because when they hit those high |
  `\   notes, I bet you can really see it in those genitals."  -- Jack |
_o__)                                                           Handey |
Ben Finney