[TIP] Testing specific code
exarkun at twistedmatrix.com
exarkun at twistedmatrix.com
Thu Sep 3 12:20:59 PDT 2009
On 06:33 pm, kumar.mcmillan at gmail.com wrote:
>>On Tue, Sep 01, 2009 at 03:46:02PM -0600, Matt Harrison wrote:
>>-> [...] As an idea to help deal with that and
>>-> to help focus coverage attention on specific code points, I thought
>>of
>>-> an idea. (I'm assuming others here have probably thought of it
>>before
>>-> to). What I'd like to do is have a (emacs) command that says 'run
>>-> tests for this function/method'. Then something
>>-> (nose??/plugin??/emacs??) goes and finds tests that invoke that
>>method
>>-> and only runs those tests and reports coverage for them.
>
>yea, this would be really slick. Holger had a good idea for this
>which is pretty straight forward and easier than grepping. You just
>add a list of test files to each code module. I.E.
>
> # content of: mymodule.py
>
> # relative paths
> __testfiles__ = ['test/test_unittest.py', 'test/test_functional.py']
>
>It's not as granular as what you're talking about but might be good
>enough for figuring out what tests to run given a function/method.
>
>To get more precise about it, yeah, you'd probably need some kind of
>trace function that kept track of what functions were executed during
>each test.
Twisted has some emacs integration code that binds F8 to run the tests
for the active buffer. If it's a test module, then it just runs that
module. If it's not, then it uses the buffer local 'test-case-name' to
decide what tests to run. Such variables are defined by a line like:
# -*- test-case-name: foo.bar,baz.quux -*-
Trial adopts this convention as well and can be asked to run the tests
which apply to a particular module.
As you say, this isn't as granular as just running the tests for a
particular line or function. I find that it's basically good enough,
though. I don't have any modules that have more than a handful of
seconds worth of tests.
I've also worked on a coverage collection tool. I've thought about
plugging this information into the test discovery code, so that the
exact set of tests for a function can be run, with knowledge of what
that set is derived from what previous test runs have done. However,
since the test-case-name thing works well enough now, I'm not really
motivated to implement that.
Jean-Paul
More information about the testing-in-python
mailing list