[TIP] Testing specific code

[exarkun at twistedmatrix.com]

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