[TIP] figleaf tests
ned at nedbatchelder.com
Mon Jun 23 18:37:41 PDT 2008
I've been down these paths too, and I completely understand Titus' wariness.
I think the stdlib module trace.py has the right idea: rather than
analyze the code at all, simply compile it, and look at the table of
line numbers in the code object. This is by definition the set of lines
that sys.settrace can return, and is very simple to read. It has the
advantage that as the compiler changes from version to version, changing
the lines that can be returned, trace.py is immune to the changes.
For more exotic ideas along these lines, you can lie about line numbers:
C. Titus Brown wrote:
> On Tue, Jun 24, 2008 at 01:43:40AM +0200, Ondrej Certik wrote:
> -> I think we need tests in a form of code snippets and corresponding
> -> numbers of all lines that can be executed and this will be checked
> -> against the LineGrabber class.
> Hi, Ondrej,
> % find figleaf/tests -name \*.py
> [ ... over 116 regression tests elided ... ]
> -> I think we should first do the tests I propose above, then you can
> -> commit this patch with a test
> -> without worrying of breaking something. Or if you have some better
> -> strategy, let me know.
> I would like to try to make a general fix by truly understanding the
> sys.settrace functionality first, writing something from the ground up
> that can correctly pick out lines that can be returned by sys.settrace,
> and then going through all the regression tests that break to make sure
> the new behavior is correct. I predict incremental approaches like you
> propose will lead to madness in this case -- at least they have for me,
> Ondrey I suspect a lot of people are confused... If you can summarize
> our private discussion, that might be good. I'm about to fly somewhere,
> so I won't get to it for a few days.
Ned Batchelder, http://nedbatchelder.com
More information about the testing-in-python