[TIP] coverage.py has slightly different results when being called from setup.py and not...
tom at swirly.com
Sat Jan 28 12:39:16 PST 2017
On 28 January 2017 at 19:42, Ned Batchelder <ned at nedbatchelder.com> wrote:
> Tom, I appreciate the work you put into investigation.
The reason gamma.py only marks line 14 as covered is because the rest of
> the file is executed before you start measuring coverage. Setup.py imports
> bibliopixel/__init__.py, which imports gamma.py, which executes all of the
> lines in the file except for line 14. Then setup.py starts coverage, and
> then your tests run, executing line 14.
> You are doing a few things you perhaps should not. Importing your product
> code into setup.py can be dangerous, because it might mean you need your
> requirements before you've had a chance to install your requirements.
Ugh, you are so right. So obvious in hindsight.
> You have no requirements, so you don't have this problem, but many
> projects go to great lengths to avoid importing the product code into
> setup.py for this reason. If you didn't import it, your coverage issue
> would be solved.
Why was this not obvious to me? In hindsight, that was the only possible
reason for the observed behavior. Well, I can fix this in seconds.
> Another unusual thing here is using setup.py to run tests. Although the
> distutils docs describe this possibility, most projects don't do it. They
> use setup.py for distribution work (building and installing kits), but not
> for other development tasks. You have a tox.ini, but are only using it to
> configure flake8! That is very unusual. Use tox to run your tests.
While I didn't actually set this part up, there's a default "test" target
in setuptools, and all sorts of machinery to run tests - so that's sort of
a trap, certainly an attractive nuisance
<https://en.wikipedia.org/wiki/Attractive_nuisance_doctrine> if nothing
I'll confer with the other maintainer/original author of this project and
see what he thinks. My theory is he might not want to change it if it's
not hurting anything.
> I hope this doesn't come off as too bossy.. :)
Oh, you must be joking - a solution to my problem and carefully worked-out
reasoning as to why? Learning something about packaging from a master?
You can be "bossy" like that any day as far as I'm concerned!
If you're ever in Amsterdam, drop by and I'll purchase you a refreshing
beverage or two of your choice. :-)
> On 1/28/17 12:36 PM, Tom Swirly wrote:
> Greetings, testy people. Thanks for this excellent package!
> I discovered coverage.py last week and have been dropping it into various
> projects I'm on. One of them only has a strangeness and I'd like to figure
> it out.
> The project is quite vanilla and doesn't use any of the trouble techniques
> listed here: https://coverage.readthedocs.io/en/coverage-4.3.4/trouble.
> --timid had no effect.
> The issue: when I run coverage from setup.py
> <http://coverage%20run%20-m%20unittest%20discover%20test%20%5C*_test.py> this
> file gamma.py
> <https://github.com/ManiacalLabs/BiblioPixel/blob/dev/bibliopixel/gamma.py> is
> marked as having only 6% coverage - nothing except line 14
> I don't even see how that would be possible, but more, there's an explicit
> test that at least loads the file
> even if it doesn't test the values - and yes, I can see that test run in my
> If I run coverage.py from the command line, like this:
> coverage run -m unittest discover test \*_test.py .
> I see 100% coverage as expected.
> Generally, I hate hitting up mailing lists until I have had a chance to
> debug the package I'm whining about ;-), but in this case I'm really not
> quite sure how to debug coverage.py, and I see no bug report I can camp on.
> (I don't think this one
> is it...)
> Thanks in advance!
> http://radio.swirly.com - art music radio 24/7 366/1000
> testing-in-python mailing listtesting-in-python at lists.idyll.orghttp://lists.idyll.org/listinfo/testing-in-python
http://radio.swirly.com - art music radio 24/7 366/1000
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the testing-in-python