[TIP] How do I get coverage on the test modules themselves?
cmcgregor at paypal.com
Tue Sep 16 08:54:23 PDT 2014
I agree with you. Covering tests seems sensible. Sometimes, in a larger system, test names get duplicated resulting in the earlier test being ignored. Other times a simple typo results in the test framework ignoring a test altogether. As tests evolve, helper methods that were once used, get dropped and dead code results.
Actually I struggled with this a bit more and now have coverage on my tests as well.
Thanks for all the support.
From: testing-in-python-bounces at lists.idyll.org [mailto:testing-in-python-bounces at lists.idyll.org] On Behalf Of Ned Batchelder
Sent: Tuesday, September 16, 2014 3:45 AM
To: testing-in-python at lists.idyll.org
Subject: Re: [TIP] How do I get coverage on the test modules themselves?
On 9/15/14 9:46 PM, Mcgregor, Cecil wrote:
I'm using coverage 3.7.1 with python 2.7.3 on Red Hat 4.1.2 linux
I've been attempting to get coverage on the test code themselves. So far coverage
seems to ignore these files.
It's not obvious from the documentation how I can do this.
How do I cover the test_*.py files as part of the coverage reports?
Others have explained the "don't cover your tests" mindset. I like coverage-measuring my tests, for the simple reason that it gives me assurance that the tests are actually running. If you've ever copy-pasted a test to make a new similar test, but forgot to change the method name, you've had tests that don't run. Coverage can find those problems.
You'll have to show us how you are running the tests. Coverage.py by default does not try to exclude test_*.py files.
testing-in-python mailing list
testing-in-python at lists.idyll.org<mailto:testing-in-python at lists.idyll.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the testing-in-python