[TIP] Testing specific code

Matt Harrison matthewharrison at gmail.com
Thu Sep 3 13:16:58 PDT 2009


On Thu, Sep 3, 2009 at 12:33 PM, Kumar McMillan<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.
>

My reasoning for grepping was that:

  * It's easy
  * If you have a public function you probably should be testing it,
so it should appear in a test.  Otherwise it should be private
(leading underscore) or so simple you don't really want to
test/examine it.

While Holger's annotations are specific and nice, they also just add
another step that appears to complicate code rather than simplify it.

If figleaf sections works then the only problem is providing a similar
solution for coverage.py.

I guess another solution would be to enable profiling, then walk up
the call graph from the function to test....  That would be precise,
and depending on the datastructure should be easy.



More information about the testing-in-python mailing list