Statement coverage tools revisited

[Edvard Majakari]

Yow,

For most of you folks Gareth Rees' excellent python code coverage tool -
/statement/ coverage tool to be more precise - is familiar, but there are
probably many TDD-fans out there who are not yet aware of this wonderful
program.

I use the tool a lot, even though it is good to be aware of common false
conceptions regarding tools counting number of visited and unvisited lines
(100% line coverage means exactly what it says and nothing more; see [1] for
more information).

However, statement coverage tools are not useless. They are very handy for
catching those blocks of code you never execute in your tests, but as
mentioned above, you shouldn't feel too secure for having 100% line coverage
for your passed unit tests.

I've only had one minor gripe with the tool, and that is the notation used
for marking visited ('>') and unvisited ('!') lines; it is not handy to grep
for '>' or '!' in annotated version, because both characters occur often in
python code. Of course you could avoid that using '^!', but it's two
keystrokes more :) and stands out less clearly in the code. That's why I did
a very simple patch for the tool, attached below [2] (it is small diff,
don't fret :), so you can even add overly-verbose line prefixes like this:

./pycoverage -a -u '>>> WARNING: NEVER VISITED' -v '>' xmlkit.py

resulting in

>class VLANRange(RangeEntry):
>    """Class for VLAN ID range nodes"""

>    def __init__(self, min_vlan_id, max_vlan_id):
...
>>> WARNING: NEVER VISITED        RangeEntry.__init__(self, ...
...

By the way, there's an interesting comment block in the heading of the code,
saying

,----
| The coverage dictionary is called "c" and the trace function
| "t".  The reason for these short names is that Python looks up variables
| by name at runtime and so execution time depends on the length of
| variables!  In the bottleneck of this application it's appropriate to
| abbreviate names to increase speed.
`----

It was written when 2.1 was the most recent stable version. I wonder if it
still applies for 2.2 and later? According to my hasty tests it doesn't
seem to be so. I didn't have very large unit test files at hand, though.

Footnotes: 

[1] http://www.garethrees.org/2001/12/04/python-coverage/

[2]

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pycoverage.diff
URL: <http://mail.python.org/pipermail/python-list/attachments/20050211/77f9ba93/attachment.ksh>
-------------- next part --------------

-- 
# Edvard Majakari		Software Engineer
# PGP PUBLIC KEY available    	Soli Deo Gloria!

"Debugging is twice as hard as writing the code in the firstplace. Therefore,
 if you write the code as cleverly as possible, you are, by definition,
 not smart enough to debug it."  -- Brian W. Kernighan