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. -- \ "Know what I hate most? Rhetorical questions." -- Henry N. Camp | `\ | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
