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

Ned Batchelder ned at nedbatchelder.com
Wed Nov 17 07:38:58 PST 2010


On 11/17/2010 8:29 AM, Ned Batchelder wrote:
> 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/**" .
>
Looking into this, I discovered something which is (subtly) documented 
about the standard library module fnmatch: its * already works like **: 
the docs say "the filename separate is not special to this module".  
This means that "a/*.txt" will match "a/foo.txt" and also 
"a/b/c/d/bar.txt".  Coverage.py uses fnmatch to match these patterns, so 
I've accidentally got entire sub-tree matching already.

> --Ned.
>
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>



More information about the testing-in-python mailing list