John Roth <[EMAIL PROTECTED]> writes: > On Oct 28, 4:56 pm, Ben Finney <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
