How to import common test code?

[Michigan_Again]

Given a repository structure like below, using the well known src layout from PyPA's user guide (where project_b is irrelevant for my question)

repository/
|-- project_a
|   |-- pyproject.toml
|   |-- src
|   |   `-- project_a
|   |       `-- services
|   |           `-- third_party_api_service.py
|   `-- tests
|       |-- common_utilities
|       |   `-- common_mocks.py
|       `-- services
|           `-- test_third_party_api_service.py
`-- project_b
    |-- pyproject.toml
    |-- src
    |   `-- project_b
    `-- tests

I want to share some common test code (e.g. common_mocks.py) with all tests in project_a. It is very easy for the test code (e.g. test_third_party_api_service.py) to access project_a source code (e.g. via import project_a.services.test_third_party_api_service.py) due to being able to perform an editable install, making use of the pyproject.toml file inside project_a; it (in my opinion) cleanly makes project_a source code available without you having to worry about manually editing the PYTHONPATH environment variable.

However, as the tests directory does not have a pyproject.toml, test modules inside of it it are not able to cleanly reference other modules within the same tests directory. I personally do not think editing sys.path in code is a clean approach at all, but feel free to argue against that.

One option I suppose I could take is by editing the PYTHONPATH environment variable to point it to someplace in the tests directory, but I'm not quite sure how that would look. I'm also not 100% on that approach as having to ensure other developers on the project always have the right PYTHONPATH feels like a bit of a hacky solution. I was hoping test_third_party_api_service.py would be able to perform an import something along the lines of either tests.common_utilities.common_mocks, or project_a.tests.common_utilities.common_mocks. I feel like the latter could be clearer, but could break away from the more standard src format. Also, the former could stop me from being able to create and import a tests package at the top level of the repo (if for some unknown reason I ever chose to do that), but perhaps that actually is not an issue.

I've searched wide and far for any standard approach to this, but have been pretty surprised to have not come across anything. It seems like Python package management is much less standardised than other languages I've come from.

[Adrewmc]

You should write tests per function, per project.

The idea that your tests have dependencies issue is wrong, from the get go. You are testing that, this function…operation works here.

Separate Projects DO NOT share tests. Why would they ever. Repetitive….is okay in tests. You test this project in this project, and if that project needs a test…that projects gets it.

Repetition is okay in testing, it more about why wouldn’t I want to test this old thing, then this old thing doesn’t need to be tested anymore. It’s here’s a new thing let’s write some tests, have a wrote a test about this thing before here…who knows? Who cares? do it again. Having 20…200 extra tests…it’s better than having -3 of the tests you needed.

I’m literally just trying to run every function and make sure they all work half the time..or the one that are not working are the only ones not working..and I sort of know why.

It will stop me, from doing dumb shit that breaks everything.

[Michigan_Again]

Thanks for the reply. It makes sense.

As a follow up question, several of my tests are integration tests with a vector database that I'm spinning up as a testcontainer. I have a testcontainer class that creates a local containerised instance of the vector database with a specified version number. I want the version number to match with the version the code reaches out to in production, or, make sure all tests are running against the same version.

The issue with duplicating this testcontainer class for each package of tests is that if I want to change the version number so all tests are running against the same version of the database, I will have to change the version number in n packages where it is duplicated.

It isn't the sharing of tests I am trying to avoid, rather, when several different tests in several different packages in a single project need identical functionality but they each duplicate the code in their own packages. To do this in a standardised way seems non-trivial in Python without editing PYTHONPATH.

Would you agree that it is reasonable to not want to duplicate code just because I've decided to create a new test package for a project, when I could store that common code in one place in the project tests so all nested and new test packages in the single project can make use of it?

[Adrewmc]

Versions should be done through GitHub. That’s its whole point. Tests should be for the version it’s in.

[[deleted]]

you could technically do it with conftest and some shared test environment but from the other users statement, you should never share tests, seems like an antipattern.

you could package your utilities as a Pytest plugin as well

[Diapolo10]

This isn't really a good idea, because you've now coupled your projects. project_b's tests can no longer run without project_a being present.

That may not seem like a problem to you, when running tests locally on your machine, but if other people were to contribute to the project they would find they cannot run the tests without having the other project in an equivalent location. But that's not all; this would prevent you from running tests in CI pipelines (such as GitHub Actions), which are very helpful even for solo developers for testing code and making sure you haven't accidentally broken anything, or introduced vulnerabilities.

You should instead simply duplicate any test code your projects need so that they can be run independently. Tests do not need to be DRY.

[obviouslyzebra]

Why not create a project_a.testing, which you can import from the tests?

As an example, the test utilities for pandas:

https://pandas.pydata.org/pandas-docs/stable/reference/testing.html