diff options
| author | Ned Batchelder <ned@nedbatchelder.com> | 2020-04-04 16:31:54 -0400 |
|---|---|---|
| committer | Ned Batchelder <ned@nedbatchelder.com> | 2020-04-04 16:50:35 -0400 |
| commit | b890a3d9f2b7a6da7d177b15b9c93e8e43810afd (patch) | |
| tree | 594d48a416ca6dd70a094e753a0e3d6da7a520dc | |
| parent | 64bd04c44135f6e03df193032619c4794bd87314 (diff) | |
| download | python-coveragepy-git-b890a3d9f2b7a6da7d177b15b9c93e8e43810afd.tar.gz | |
Make the questions heading so they can be linked to
| -rw-r--r-- | doc/faq.rst | 23 |
1 files changed, 14 insertions, 9 deletions
diff --git a/doc/faq.rst b/doc/faq.rst index ca795729..6a0a51fa 100644 --- a/doc/faq.rst +++ b/doc/faq.rst @@ -11,7 +11,8 @@ FAQ and other help Frequently asked questions -------------------------- -**Q: Why do unexecutable lines show up as executed?** +Q: Why do unexecutable lines show up as executed? +................................................. Usually this is because you've updated your code and run coverage.py on it again without erasing the old data. Coverage.py records line numbers executed, @@ -22,8 +23,8 @@ If old data is persisting, you can use an explicit ``coverage erase`` command to clean out the old data. -**Q: Why do the bodies of functions (or classes) show as executed, but the def -lines do not?** +Q: Why do the bodies of functions show as executed, but the def lines do not? +............................................................................. This happens because coverage.py is started after the functions are defined. The definition lines are executed without coverage measurement, then @@ -36,8 +37,8 @@ monitored. If you are using the :ref:`API <api>`, you need to call coverage.start() before importing the modules that define your functions. -**Q: My decorator lines are marked as covered, but the "def" line is not. -Why?** +Q: My decorator lines are marked as covered, but the "def" line is not. Why? +............................................................................. Different versions of Python report execution on different lines. Coverage.py adapts its behavior to the version of Python being used. In Python 3.7 and @@ -47,7 +48,8 @@ reported. If you collect execution data on Python 3.7, and then run coverage reports on Python 3.8, there will be a discrepancy. -**Q: How is the total percentage calculated?** +Q: How is the total percentage calculated? +.......................................... Coverage.py counts the total number of possible executions. This is the number of executable statements minus the number of excluded statements. It then @@ -67,7 +69,8 @@ show the number of partial branches, which is the lines that were executed but did not execute all of their exits. -**Q: Coverage.py is much slower than I remember, what's going on?** +Q: Coverage.py is much slower than I remember, what's going on? +............................................................... Make sure you are using the C trace function. Coverage.py provides two implementations of the trace function. The C implementation runs much faster. @@ -80,7 +83,8 @@ Try re-installing coverage.py to see what happened and if you get the CTracer as you should. -**Q: Isn't coverage testing the best thing ever?** +Q: Isn't coverage testing the best thing ever? +.............................................. It's good, but `it isn't perfect`__. @@ -106,7 +110,8 @@ __ https://nedbatchelder.com/blog/200710/flaws_in_coverage_measurement.html .. _django-coverage: https://pypi.org/project/django-coverage/ -**Q: Where can I get more help with coverage.py?** +Q: Where can I get more help with coverage.py? +.............................................. You can discuss coverage.py or get help using it on the `Testing In Python`_ mailing list. |