On Oct 28, 9:15 pm, Ben Finney <[EMAIL PROTECTED]> wrote: > Kay Schluehr <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
