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

[Ben Finney]

Kay Schluehr <kay.schluehr at gmx.net> writes:

> I used to write once a coverage tool ( maybe I can factor this out
> of my tool suite some time )

That'd be wonderful. I'd like to see comparisons between different
test-coverage tools, just as we have the different but comparable
'pyflakes' and 'pylint' code inspection tools.

> Given it's nature it might act transformative. So a statement:
> 
> if a and b:
>     BLOCK
> 
> can be transformed into
> 
> if a:
>     if b:
>         BLOCK

I don't see that this actually helps in the cases described in the
original post. The lack of coverage checking isn't "are both sides of
an 'and' or 'or' expression evaluated", since that's the job of the
language runtime, and is outside the scope of our unit test.

what needs to be tested is "do the tests execute both the 'true' and
'false' branches of this 'if' statement", or "do the tests exercise
the 'no iterations' case for this loop", et cetera. That is, whether
all the functional branches are exercised by tests, not whether the
language is parsed correctly.

-- 
 \    "Know what I hate most? Rhetorical questions."  -- Henry N. Camp |
  `\                                                                   |
_o__)                                                                  |
Ben Finney