[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