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

[John Roth]

On Oct 28, 9:15 pm, Ben Finney <bignose+hates-s... at benfinney.id.au>
wrote:
> Kay Schluehr <kay.schlu... 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.

Since 'and' and 'or' are short-circuit evaluations, you do need
something to determine if each piece was actually executed. Turning it
into an if-else construct would do this nicely.

John Roth

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