[TIP] branch coverage
Andrew Dalke
dalke at dalkescientific.com
Thu Jan 24 16:02:31 PST 2008
m h <sesquile at gmail.com> wrote:
> I think generate both if you could. The python code may be ugly, but
> it does an excellent job of explaining how complicated code can
> actually get. I also serves well to illustrate the differences
> between the different types of coverage (line, branch, path).
I've been trying to figure out how to handle more complicated
situations, like
if (1 + (a or b) and (c if d else e) - 8):
...
It gets pretty hairy. In essence
AND(
PLUS(1, OR(a, b)),
MINUS(IF_EXPR(d, c, e), 8)
)
which gets turned into
result_1 = 1
if a:
test_is_true(1)
result_2 = a
else:
test_is_false(1)
result_2 = b
result_1 = result_1 + result_2
if result_1:
test_is_true(2)
if d:
test_is_true(3)
result_3 = c
else:
test_is_false(3)
result_3 = e
result_4 = result_3 - 8
if result_4:
test_is_true(4)
result_5 = True
else:
test_is_false(4)
result_5 = False
else:
test_is_false(2)
result_5 = False
if result_5:
...
The byte compiler already does this so adding support for calling
"test_is_true" and "test_is_false", and statement coverage, would be
simple. I think.
I don't think anyone's going to sit down and get anything more
informative from this level of detail, when documentation (ha! this
is an idea for a lightning talk) would be as educational or more.
In addition, the line numbers will be wrong, the comments stripped,
line continuations removed, and probably it'll be more messed up than
that.
On Jan 24, 2008, at 9:16 PM, Titus Brown wrote:
> 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...
I'm worried about any confusion between instrumented .pyc vs.
normal .pyc. Eh, but I'll start out simple and see what confusion
happens.
> IMO only, but I think people will want as much detail as possible.
I'm thinking that the instrumentation compiler could take an optional
flag saying which module should be imported for event logging.
People who want more details could easily do that.
But if you want more detail, there'll be a full Python parser so you
can do whatever you want. :)
On Jan 24, 2008, at 10:11 PM, Kumar McMillan wrote:
> did you think about using the tokenize module?
> http://docs.python.org/lib/module-tokenize.html
I'm using some of the tokenize module. I wanted everything to be in
PLY, although it wouldn't be too hard to make an adapter between
them. I think that tokenize is a more concise module than my code,
although mine also checks for the indentation level.
I'm basing it on work I did to understand how to parse indentation
based languages. See for examples my GardenSnake and LOLPython
implementations.
http://www.dalkescientific.com/writings/diary/archive/2006/08/30/
gardensnake_language.html
http://www.dalkescientific.com/writings/diary/archive/2007/06/01/
lolpython.html
On Jan 24, 2008 1:54 PM, m h <sesquile at gmail.com> wrote:
> If I call a function, I want to
> know what parts of code were executed during that call. And I want it
> to be separate from other invocations of that function.
Let me get the code into a shape where it makes sense to anyone else
and then you can have fun. :)
(And all the Lisp users are probably laughing, saying "Python needs
macros - duh!" :)
Andrew
dalke at dalkescientific.com
More information about the testing-in-python
mailing list