Skip to main content
Version: 2.14 (deprecated)

pytest

The pytest Python test framework (https://docs.pytest.org/).

Backend: pants.backend.python

Config section: [pytest]

Basic options​

args​

--pytest-args="[<shell_str>, <shell_str>, ...]", ... -- [<shell_str> [<shell_str> [...]]]
PANTS_PYTEST_ARGS
pants.toml
[pytest]
args = [
    <shell_str>,
    <shell_str>,
    ...,
]
default: []

Arguments to pass directly to Pytest, e.g. --pytest-args='-k test_foo --quiet'.

export​

--[no-]pytest-export
PANTS_PYTEST_EXPORT
pants.toml
[pytest]
export = <bool>
default: True

If true, export a virtual environment with Pytest when running /home/josh/work/scie-pants/dist/pants export.

This can be useful, for example, with IDE integrations to point your editor to the tool's binary.

xdist_enabled​

--[no-]pytest-xdist-enabled
PANTS_PYTEST_XDIST_ENABLED
pants.toml
[pytest]
xdist_enabled = <bool>
default: False

If true, Pants will use pytest-xdist (https://pytest-xdist.readthedocs.io/en/latest/) to parallelize tests within each python_test target.

NOTE: Enabling pytest-xdist can cause high-level scoped fixtures (for example session) to execute more than once. See the pytest-xdist docs for more info: https://pypi.org/project/pytest-xdist/#making-session-scoped-fixtures-execute-only-once

Advanced options​

config​

--pytest-config=<file_option>
PANTS_PYTEST_CONFIG
pants.toml
[pytest]
config = <file_option>
default: None

Path to a config file understood by Pytest (https://docs.pytest.org/en/latest/reference/customize.html#configuration-file-formats). Setting this option will disable [pytest].config_discovery. Use this option if the config is located in a non-standard location.

config_discovery​

--[no-]pytest-config-discovery
PANTS_PYTEST_CONFIG_DISCOVERY
pants.toml
[pytest]
config_discovery = <bool>
default: True

If true, Pants will include all relevant Pytest config files (e.g. pytest.ini) during runs. See https://docs.pytest.org/en/stable/customize.html#finding-the-rootdir for where config files should be located for Pytest to discover them.

Use [pytest].config instead if your config is in a non-standard location.

console_script​

--pytest-console-script=<str>
PANTS_PYTEST_CONSOLE_SCRIPT
pants.toml
[pytest]
console_script = <str>
default: pytest

The console script for the tool. Using this option is generally preferable to (and mutually exclusive with) specifying an --entry-point since console script names have a higher expectation of staying stable across releases of the tool. Usually, you will not want to change this from the default.

entry_point​

--pytest-entry-point=<str>
PANTS_PYTEST_ENTRY_POINT
pants.toml
[pytest]
entry_point = <str>
default: None

The entry point for the tool. Generally you only want to use this option if the tool does not offer a --console-script (which this option is mutually exclusive with). Usually, you will not want to change this from the default.

execution_slot_var​

--pytest-execution-slot-var=<str>
PANTS_PYTEST_EXECUTION_SLOT_VAR
pants.toml
[pytest]
execution_slot_var = <str>
default: None

If a non-empty string, the process execution slot id (an integer) will be exposed to tests under this environment variable name.

extra_requirements​

--pytest-extra-requirements="['<str>', '<str>', ...]"
PANTS_PYTEST_EXTRA_REQUIREMENTS
pants.toml
[pytest]
extra_requirements = [
    '<str>',
    '<str>',
    ...,
]
default: 
[
  "pytest-cov>=2.12,!=2.12.1,<3.1",
  "pytest-xdist>=2.5,<3"
]

Any additional requirement strings to use with the tool. This is useful if the tool allows you to install plugins or if you need to constrain a dependency to a certain version.

junit_family​

--pytest-junit-family=<str>
PANTS_PYTEST_JUNIT_FAMILY
pants.toml
[pytest]
junit_family = <str>
default: xunit2

The format of generated junit XML files. See https://docs.pytest.org/en/latest/reference.html#confval-junit_family.

lockfile​

--pytest-lockfile=<str>
PANTS_PYTEST_LOCKFILE
pants.toml
[pytest]
lockfile = <str>
default: <default>

Path to a lockfile used for installing the tool.

Set to the string <default> to use a lockfile provided by Pants, so long as you have not changed the --version and --extra-requirements options, and the tool's interpreter constraints are compatible with the default. Pants will error or warn if the lockfile is not compatible (controlled by [python].invalid_lockfile_behavior). See https://github.com/pantsbuild/pants/blob/release_2.14.2/src/python/pants/backend/python/subsystems/pytest.lock for the default lockfile contents.

Set to the string <none> to opt out of using a lockfile. We do not recommend this, though, as lockfiles are essential for reproducible builds and supply-chain security.

To use a custom lockfile, set this option to a file path relative to the build root, then run /home/josh/work/scie-pants/dist/pants generate-lockfiles --resolve=pytest.

Alternatively, you can set this option to the path to a custom lockfile using pip's requirements.txt-style, ideally with --hash. Set [python].invalid_lockfile_behavior = 'ignore' so that Pants does not complain about missing lockfile headers.

version​

--pytest-version=<str>
PANTS_PYTEST_VERSION
pants.toml
[pytest]
version = <str>
default: pytest==7.0.1

Requirement string for the tool.

Deprecated options​

timeout_default​

--pytest-timeout-default=<int>
PANTS_PYTEST_TIMEOUT_DEFAULT
pants.toml
[pytest]
timeout_default = <int>
default: None
Deprecated, will be removed in version: 2.15.0.dev1.
Use `timeout_default` option in the `test` scope instead.

The default timeout (in seconds) for a test target if the timeout field is not set on the target.

timeout_maximum​

--pytest-timeout-maximum=<int>
PANTS_PYTEST_TIMEOUT_MAXIMUM
pants.toml
[pytest]
timeout_maximum = <int>
default: None
Deprecated, will be removed in version: 2.15.0.dev1.
Use `timeout_maximum` option in the `test` scope instead.

The maximum timeout (in seconds) that may be used on a python_tests target.

timeouts​

--[no-]pytest-timeouts
PANTS_PYTEST_TIMEOUTS
pants.toml
[pytest]
timeouts = <bool>
default: True
Deprecated, will be removed in version: 2.15.0.dev1.
Use `timeouts` option in the `test` scope instead.

Enable test target timeouts. If timeouts are enabled then test targets with a timeout= parameter set on their target will time out after the given number of seconds if not completed. If no timeout is set, then either the default timeout is used or no timeout is configured.

None