Working with conftest.py fixtures in a Python monorepo

[alexey-tereshenkov-aiven]

In the layout of a monorepo

project1
  tests/
    conftest.py (with project1 specific fixtures)
    test_module.py
project2
  tests/
    conftest.py (with project2 specific fixtures)
    test_module.py
conftest.py (with generic fixtures)

when running tests in project1/tests directory, pytest visits all ancestor directories until reaching the root collecting all conftest.py so that fixtures are available.

From the docs:

Pants will also infer dependencies on any confest.py files in the current directory and any ancestor directories, which mirrors how Pytest behaves.

This means that when making changes to the root conftest.py, all tests will need to be run because every test depends on that root conftest.py. It's possible to disable this behavior:

You can turn off this feature by setting conftests = false in the [python-infer] scope.

However, it seems fair that all subprojects may want to use a generic fixture from the root conftest.py. But this negatively affects the dependency management within tests as all tests (some of them may take a lot of time to complete!) will need to be run every time someone touches the root conftest.py (since you don't know whether the fixtures a test uses are actually modified).

Importing individual fixtures (so that you would split the root conftest.py into individual modules) seems to be discouraged: pytest docs suggest you define all your fixtures within one single conftest.py file. There is an explicit import approach, but I am not sure what are the cons of this approach?

# tests/conftest.py
import pytest
from fixtures.add import add

I see usage of

pytest_plugins = (
   "fixtures.fixture_1",
   "fixtures.fixture_2",
)

in various repositories, but this doesn't work well with Pants dependency inference (as there are no import statements).

What kind of approach have you decided to go with?

[thejcannon]

in various repositories, but this doesn't work well with Pants dependency inference (as there are no import statements).

If you turn on string import matching, this would work, FYI (we do it at our org)

[alexey-tereshenkov-aiven]

Thanks, Josh. That's helpful. I've tried a few variations having the pytest_plugins declared in a test module and a root conftest.py with pants.toml having [python-infer].string_imports = true.

So adding pytest_plugins = ["tests.plugins.handy"] to a test module (having handy.py in the tests.plugins package is not enough, since Pants doesn't list the tests/plugins/handy.py as part of the dependencies of the test module running ./pants dependencies tests/test_module.py.

What part am I missing? :/

[thejcannon]

It's relative to your source roots I think. What's your source roots?

[alexey-tereshenkov-aiven]

Let me fire up an example-python draft PR so that we could make a minimal reproducible example!

[AlexTereshenkov]

Thanks @thejcannon, got it working with AlexTereshenkov/example-python#2. It does work indeed. I'll explore if that's a feasible path to take.

[thejcannon]

I don't think there's a one-size-fits-all answer. I think it's really a crossroads of choices you and your team get to decide on.

Things like remote caching and test layout affect the choices you'll make.

However, my general rule of thumb for conftest.py files is "as low in the tree as I can shove it" precisely for this reason. Otherwise I don't like making my engs have to think about Pants, so I don't mind a bit of cache invalidation to be doing things "the normal way".

[ericfeunekes]

I actually prefer your approach, that's what I do in my repo. The best way I've found (forget where I found this) is to create a top level conftest that imports the the subdirectory conftests as plugins. This is the code I use:

def refactor(string: str) -> str:
    return string.replace("/", ".").replace("\\", ".").replace(".py", "")


pytest_plugins = [
    refactor(conftest)
    for conftest in glob("tests/**/conftests.py", recursive=True)
    if "__" not in conftest
]

This way would help achieve what you're looking for because you would have a top level conftest that would only hold fixtures that are truly applicable to the whole repo, then you could define fixtures in the sub-conftest files, which would work in any pytest run.

[jriddy]

This seems like the opposite of what I'd want, as it effectively makes all fixtures defined everywhere in your tests tree available to all tests. And Pants wouldn't be able to scan for this kinda dependency detection either.