Specifying source files

When coverage.py is running your program and measuring its execution, it needs to know what code to measure and what code not to. Measurement imposes a speed penalty, and the collected data must be stored in memory and then on disk. More importantly, when reviewing your coverage reports, you don’t want to be distracted with modules that aren’t your concern.

Coverage.py has a number of ways you can focus it in on the code you care about.

Execution

When running your code, the coverage run command will by default measure all code, unless it is part of the Python standard library.

You can specify source to measure with the --source command-line switch, or the [run] source configuration value. The value is a comma- or newline-separated list of directories or importable names (packages or modules).

If the source option is specified, only code in those locations will be measured. Specifying the source option also enables coverage.py to report on un-executed files, since it can search the source tree for files that haven’t been measured at all. Only importable files (ones at the root of the tree, or in directories with a __init__.py file) will be considered. Files with unusual punctuation in their names will be skipped (they are assumed to be scratch files written by text editors). Files that do not end with .py, .pyw, .pyo, or .pyc will also be skipped.

Note

Modules named as sources may be imported twice, once by coverage.py to find their location, then again by your own code or test suite. Usually this isn’t a problem, but could cause trouble if a module has side-effects at import time.

Exceptions during the early import are suppressed and ignored.

You can further fine-tune coverage.py’s attention with the --include and --omit switches (or [run] include and [run] omit configuration values). --include is a list of file name patterns. If specified, only files matching those patterns will be measured. --omit is also a list of file name patterns, specifying files not to measure. If both include and omit are specified, first the set of files is reduced to only those that match the include patterns, then any files that match the omit pattern are removed from the set.

The include and omit file name patterns follow common shell syntax, described below in File patterns. Patterns that start with a wildcard character are used as-is, other patterns are interpreted relative to the current directory:

  • .coveragerc
  • pyproject.toml
  • setup.cfg, tox.ini
[run]
omit =
    # omit anything in a .local directory anywhere
    */.local/*
    # omit everything in /usr
    /usr/*
    # omit this single file
    utils/tirefire.py
[tool.coverage.run]
omit = [
    # omit anything in a .local directory anywhere
    "*/.local/*",
    # omit everything in /usr
    "/usr/*",
    # omit this single file
    "utils/tirefire.py",
    ]
[coverage:run]
omit =
    # omit anything in a .local directory anywhere
    */.local/*
    # omit everything in /usr
    /usr/*
    # omit this single file
    utils/tirefire.py

The source, include, and omit values all work together to determine the source that will be measured.

If both source and include are set, the include value is ignored and a warning is issued.

Reporting

Once your program is measured, you can specify the source files you want reported. Usually you want to see all the code that was measured, but if you are measuring a large project, you may want to get reports for just certain parts.

The report commands (report, html, json, lcov, annotate, and xml) all take optional modules arguments, and --include and --omit switches. The modules arguments specify particular modules to report on. The include and omit values are lists of file name patterns, just as with the run command.

Remember that the reporting commands can only report on the data that has been collected, so the data you’re looking for may not be in the data available for reporting.

Note that these are ways of specifying files to measure. You can also exclude individual source lines. See Excluding code from coverage.py for details.

File patterns

File path patterns are used for include and omit, and for combining path remapping. They follow common shell syntax:

  • ? matches a single file name character.

  • * matches any number of file name characters, not including the directory separator. As a special case, if a pattern starts with */, it is treated as **/, and if a pattern ends with /*, it is treated as /**.

  • ** matches any number of nested directory names, including none. It must be used as a full component of the path, not as part of a word: /**/ is allowed, but /a**/ is not.

  • Both / and \ will match either a slash or a backslash, to make cross-platform matching easier.

  • A pattern with no directory separators matches the file name in any directory.

Some examples:

Pattern

Matches

Doesn’t Match

a*.py

anything.py
sub1/sub2/another.py
cat.py

sub/*/*.py

sub/a/main.py
sub/b/another.py
sub/foo.py
sub/m1/m2/foo.py

sub/**/*.py

sub/something.py
sub/a/main.py
sub/b/another.py
sub/m1/m2/foo.py
sub1/anything.py
sub1/more/code/main.py

*/sub/*

some/where/sub/more/something.py
sub/hello.py
sub1/anything.py

*/sub*/*

some/where/sub/more/something.py
sub/hello.py
sub1/anything.py
some/more/something.py

*/*sub/test_*.py

some/where/sub/test_everything.py
moresub/test_things.py
some/where/sub/more/test_everything.py
more/test_things.py

*/*sub/*sub/**

sub/sub/something.py
asub/bsub/more/thing.py
code/sub/sub/code.py
sub/something.py