Doc on conftest.py
hook interactions with pytest_addoption()
possibly misleading
#13304
Open
4 tasks done
Labels
topic: config
related to config handling, argument parsing and config file
type: docs
documentation improvement, missing or needing clarification
Summary
The doc page "Writing hook functions" seems to suggest that
conftest.py
hooks are available atpytest_addoption()
time, which isn't the case; only hooks installed by other third-party plugins are (EDIT (19 Mar): sometimes; see edit below).Details
On the aforementioned page, the section "Using hooks in pytest_addoption" contains a minimal example of a plugin
myplugin
which defines a hookpytest_config_file_default_value()
, from whichpytest_addoption()
should be able to extract a user-defined default for the command-line option--config-file
viapluginmanager.hook
(excerpt of the code block):It then goes on to say
Maybe I'm misinterpreting, but it seems that it is implied that
conftest.py::pytest_config_file_default_value()
should be available at the time whenmyplugin.py::pytest_addoption()
is executed, and thus the help text for the--config-file
option should readConfig file to use, defaults to config.yaml
.However, as the minimal example in the section below demonstrates,
conftest.py
implementations of hooks aren't visible topluginmanager.hook
at the timepytest_addoption()
is run, while implementations living in other installed plugins are.Example
(EDIT (19 Mar): made collapsible; click to expand)
Unless I'm mistaken, since the
conftest.py
lives in the directory explicitly supplied as atestpath
, it should qualify as an "initial"conftest.py
file. Nonetheless, running the above example shows that onlyplugin-2/plugin_2.py::pytest_foo_default()
were picked up byplugin-1/plugin_1.py::pytest_addoption()
, but notpackage-3/tests/conftest.py::pytest_foo_default()
.While it is understandable that
conftest.py
configurations are located and loaded later than when the command-line options are defined, this contradicts what the above aforementioned doc seem to imply – that command-line option defaults can be loaded therefrom. Maybe it could use some clarification?Versions and platform info
EDIT (19 Mar 2025)
In one of the tests for some plugin (see e.g.
plugin-1
in the Example), I once wrote something like the below to test the aforementioned availability of hook implementations atpytest_addoption()
time:Test code (click to expand)
However, the test only passed around 50% of the time, failing on the last assertion. Examining the output of the first
runpytest()
call revealed that the'bar'
default is only available if the dynamically-generated plugin is loaded before the one I'm testing, but it's a coin toss whether that or the opposite happens. And since we don't have a way to control the ordering between third-party plugins yet (#935), it seems that there is no way to make plugin-supplied default values available when the command-line options are generated.One exception is when a plugin defines the hook spec, a plugin (could be the same or another) supplies the hook implementation, and the
conftest.py
adds the command-line flag by definingpytest_addoption()
. But that seems to be diametrically opposite to what the doc example says.Checklist
pip list
from the virtual environment you are usingThe text was updated successfully, but these errors were encountered: