| Index: tools/telemetry/third_party/coverage/doc/howitworks.rst
|
| diff --git a/tools/telemetry/third_party/coverage/doc/howitworks.rst b/tools/telemetry/third_party/coverage/doc/howitworks.rst
|
| new file mode 100644
|
| index 0000000000000000000000000000000000000000..74747e80863bc4e7460c6c5520d2cb79fa47c841
|
| --- /dev/null
|
| +++ b/tools/telemetry/third_party/coverage/doc/howitworks.rst
|
| @@ -0,0 +1,97 @@
|
| +.. Licensed under the Apache License: http://www.apache.org/licenses/LICENSE-2.0
|
| +.. For details: https://bitbucket.org/ned/coveragepy/src/default/NOTICE.txt
|
| +
|
| +.. _howitworks:
|
| +
|
| +=====================
|
| +How Coverage.py works
|
| +=====================
|
| +
|
| +.. :history: 20150812T071000, new page.
|
| +
|
| +For advanced use of coverage.py, or just because you are curious, it helps to
|
| +understand what's happening behind the scenes. Coverage.py works in three
|
| +phases:
|
| +
|
| +* **Execution**: Coverage.py runs your code, and monitors it to see what lines
|
| + were executed.
|
| +
|
| +* **Analysis**: Coverage.py examines your code to determine what lines could
|
| + have run.
|
| +
|
| +* **Reporting**: Coverage.py combines the results of execution and analysis to
|
| + produce a coverage number and an indication of missing execution.
|
| +
|
| +The execution phase is handled by the ``coverage run`` command. The analysis
|
| +and reporting phases are handled by the reporting commands like ``coverage
|
| +report`` or ``coverage html``.
|
| +
|
| +Let's look at each phase in more detail.
|
| +
|
| +
|
| +Execution
|
| +---------
|
| +
|
| +At the heart of the execution phase is a Python trace function. This is a
|
| +function that the Python interpreter invokes for each line executed in a program.
|
| +Coverage.py implements a trace function that records each file and line number
|
| +as it is executed.
|
| +
|
| +Executing a function for every line in your program can make execution very
|
| +slow. Coverage.py's trace function is implemented in C to reduce that
|
| +slowdown. It also takes care to not trace code that you aren't interested in.
|
| +
|
| +When measuring branch coverage, the same trace function is used, but instead of
|
| +recording line numbers, coverage.py records pairs of line numbers. Each
|
| +invocation of the trace function remembers the line number, then the next
|
| +invocation records the pair `(prev, this)` to indicate that execution
|
| +transitioned from the previous line to this line. Internally, these are called
|
| +arcs.
|
| +
|
| +For more details of trace functions, see the Python docs for `sys.settrace`_,
|
| +or if you are really brave, `How C trace functions really work`_.
|
| +
|
| +At the end of execution, coverage.py writes the data it collected to a data
|
| +file, usually named ``.coverage``. This is a JSON-based file containing all of
|
| +the recorded file names and line numbers executed.
|
| +
|
| +.. _sys.settrace: https://docs.python.org/3/library/sys.html#sys.settrace
|
| +.. _How C trace functions really work: http://nedbatchelder.com/text/trace-function.html
|
| +
|
| +
|
| +Analysis
|
| +--------
|
| +
|
| +After your program has been executed and the line numbers recorded, coverage.py
|
| +needs to determine what lines could have been executed. Luckily, compiled
|
| +Python files (.pyc files) have a table of line numbers in them. Coverage.py
|
| +reads this table to get the set of executable lines, with a little more source
|
| +analysis to leave out things like docstrings.
|
| +
|
| +The data file is read to get the set of lines that were executed. The
|
| +difference between the executable lines, and the executed lines, are the lines
|
| +that were not executed.
|
| +
|
| +The same principle applies for branch measurement, though the process for
|
| +determining possible branches is more involved. Coverage.py reads the bytecode
|
| +of the compiled Python file, and decides on a set of possible branches.
|
| +Unfortunately, this process is inexact, and there are some `well-known cases`__
|
| +that aren't correct.
|
| +
|
| +.. __: https://bitbucket.org/ned/coveragepy/issues?status=new&status=open&component=branch
|
| +
|
| +
|
| +Reporting
|
| +---------
|
| +
|
| +Once we have the set of executed lines and missing lines, reporting is just a
|
| +matter of formatting that information in a useful way. Each reporting method
|
| +(text, html, annotated source, xml) has a different output format, but the
|
| +process is the same: write out the information in the particular format,
|
| +possibly including the source code itself.
|
| +
|
| +
|
| +Plugins
|
| +-------
|
| +
|
| +Plugins interact with these phases.
|
|
|