Code coverage measurement for Python
http://pypi.python.org/coverage
Coverage.py measures code coverage, typically during test execution. It uses
the code analysis tools and tracing hooks provided in the Python standard
library to determine which lines are executable, and which have been executed.
- Sources inherited from project openSUSE:Leap:42.3
-
1
derived packages
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout openSUSE:Leap:42.3:Ports/python-coverage && cd $_
- Create Badge
Refresh
Refresh
Source Files
Filename | Size | Changed |
---|---|---|
coverage-4.3.4.tar.gz | 0000361491 353 KB | |
python-coverage.changes | 0000015088 14.7 KB | |
python-coverage.spec | 0000002881 2.81 KB |
Latest Revision
Ludwig Nussel (lnussel_factory)
accepted
request 501725
from
Dirk Mueller (dirkmueller)
(revision 6)
- uninstall alternatives in %postun - update for singlespec - update to 4.3.4: - Using the --skip-covered option on an HTML report with 100% coverage would cause a “No data to report” error, as reported in issue 549. This is now fixed; thanks, Loïc Dachary. - If-statements can be optimized away during compilation, for example, if 0: or if __debug__:. Coverage.py had problems properly understanding these statements which existed in the source, but not in the compiled bytecode. This problem, reported in issue 522, is now fixed. - If you specified --source as a directory, then coverage.py would look for importable Python files in that directory, and could identify ones that had never been executed at all. But if you specified it as a package name, that detection wasn’t performed. Now it is, closing issue 426. Thanks to Loïc Dachary for the fix. - If you started and stopped coverage measurement thousands of times in your process, you could crash Python with a “Fatal Python error: deallocating None” error. This is now fixed. Thanks to Alex Groce for the bug report. - On PyPy, measuring coverage in subprocesses could produce a warning: “Trace function changed, measurement is likely wrong: None”. This was spurious, and has been suppressed. - Previously, coverage.py couldn’t start on Jython, due to that implementation missing the multiprocessing module (issue 551). This problem has now been fixed. Also, issue 322 about not being able to invoke coverage conveniently, seems much better: jython -m coverage run myprog.py works properly. - Let’s say you ran the HTML report over and over again in the same output directory, with --skip-covered. And imagine due to your heroic test-writing efforts, a file just acheived the goal of 100% coverage. With coverage.py
Comments 0