[TIP] branch coverage

Titus Brown titus at caltech.edu
Thu Jan 24 12:16:09 PST 2008


[ munch ]

Andrew, this looks great!

-> I could generate raw Python code, which would be ugly, have the  
-> comments stripped out, and line numbers changed.  Or I could generate  
-> byte code.

I think byte code is cleaner.

-> If the latter, I was thinking to write a .py -> .pyc compiler, but do  
-> I use it like compileall?  Or do I generate the .pyc files in another  
-> directory, which is used for the coverage testing.  Where do I keep  
-> the coverage results?  Probably all in a single directly, named after  
-> the Python module name.

Can you just generate .pyc files in the normal place, i.e. same
directory?  How would this affect 'execfile'd code -- presumably you'd
need to treat scripts differently...

And, for the love of god, put a simple API on top of the coverage
results.  Half the reason I wrote figleaf was that I needed to
manipulate the output of coverage, and it was quite difficult to do so
for several reasons.  Not having a query-able internal data structure is
one of those reasons.

-> Do people only care about if the branch was true/false or are the  
-> number of tests also important?  What about the number of times a  
-> line was executed, vs. a flag saying that it was covered?

IMO only, but I think people will want as much detail as possible.

cheers,
--titus



More information about the testing-in-python mailing list