[TIP] Coverage 3.4: modules in "source" but file patterns in "omit"?

Ned Batchelder ned at nedbatchelder.com
Wed Nov 17 05:29:12 PST 2010


On 11/15/2010 6:29 AM, Geoff Bache wrote:
> Hi all,
>
> Just upgraded to coverage 3.4 - very pleased it's possible to specify
> where my source is now...
>
> I am however a bit confused as to why the "source" and "omit" settings
> refer to modules in different ways.
>
> I have the following situation: I have program 'myprog' and module
> 'mymodule' to test. 'myprog' depends on 'mymodule'. Both have their
> own test suite, but in the case of 'mymodule', some parts are covered
> only by the 'myprog' tests. So I would like 3 reports out: coverage of
> myprog, coverage of mymodule, and coverage of mymodule including
> myprog's tests. Without needing to run myprog's tests more than once.
>
> myprog is run from its source tree, whereas mymodule is installed.
>
> My coveragerc file for myprog therefore looks like this
>
> [run]
> source = /source/directory/containing/myprog,mymodule
>
> [report]
> omit = /long/path/python2.6/lib/python2.6/site-packages/mymodule/*,/long/path/python2.6/lib/python2.6/site-packages/mymodule/*/*,/long/path/python2.6/lib/python2.6/site-packages/mymodule/*/*/*
>
> which seems a rather convoluted and brittle way of excluding mymodule
> in this report, especially when the setting above handles it more
> concisely. Why don't these two settings don't allow referring to the
> same entities in the same way?
>
The specification of source files has changed over time, and there are 
lots of different use cases, so it's hard to get it just right for 
everyone.  One possibility is to allow referring to modules by module 
name in the omit (and include) settings.  This is a little more involved 
than it seems at first blush, though, because we only really know what 
module names mean when we're executing the code.  And we need to apply 
the omit settings while generating the reports, so to make this work 
right, coverage.py would have to write a module map into the .coverage 
data files.  Then I'm sure someone (perhaps you, Geoff! :)  ) would 
present us with the tricky case of combining multiple data files where 
the same module name mapped to different files during different runs, 
because of multiple OS's.

Another possibility to make your config simpler would be to allow "**" 
syntax in the omit setting, so at least you would only write 
"/long/path/python2.6/lib/python2.6/site-packages/mymodule/**" .

--Ned.




More information about the testing-in-python mailing list