Correct way to share code between tests of different components

[james-hollingsworth]

Hi,

We recently started using python-polylith to build out our new monorepo. It's going well, and as the number of components we create is increasing - we're coming across cases where it makes sense to share test code between components. E.g. fixtures, stubs and utilities.

Say we have a component foo, who's tests need to use bar's fixtures (but equally it could be bar's test utilities etc). We've been able to achieve this like so:
from components.bar.test.bar import fixtures

I just wanted to confirm whether this is the suggested way to achieve this, or whether there is an alternative approach we should be using?

Thanks,
James

[hstravis]

We did something similar. To prevent test code from polluting components, we created a test_utils component and put component-specific test code in submodules of test_utils. In your example, I think test code for foo and bar would be located in bar.test_utils.foo and bar.test_utils.bar respectively.

That way test code is reusable but separate from components so it doesn't slip into project artifacts (i.e. Docker images and pip packages).

Side note: components should not be a module. To import fixtures, it should be: from bar.test.bar import fixtures. To make that work, we had to add components and bases to our PYTHONPATH. Like this:

export PYTHONPATH="${PWD}/components:${PWD}/bases"

We use VS Code for python development so we had to set the PYTHONPATH in .vscode/settings.json like this:

    // enable polylith to work with VS Code
    // enables references to start from 'components' and 'base' dirs instead of root
    "python.analysis.extraPaths": ["components", "bases"],
    "python.autoComplete.extraPaths": ["components", "bases"],
    "terminal.integrated.env.linux": {
        "PYTHONPATH": "${workspaceFolder}/components:${workspaceFolder}/bases"
    },
    "terminal.integrated.env.windows": {
        "PYTHONPATH": "${workspaceFolder}\\components;${workspaceFolder}\\bases"
    },

[DavidVujic]

You also can have test-specific code (helpers/utils) within the test folder. To make the test-specific code available for the tests, I would add it in the root pyproject.toml:

(example, using Poetry)

# NOTE: this is only added in the root pyproject.toml, i.e. the "development" project
packages [
    ...
   {include = "test_helpers", from = "test"},
]

Here, the test_helpers are added in the packages section. This will make it possible to import:

# this is a unit test in the tests/components/<the-top-namespace>/<the-package-to-tests> folder

# importing the helper/common to be used by tests only
from test_helpers import test_data

def test_something():
    data = test_data.helloworld()
    ....

For fixtures I would recommend the built-in features of pytest: adding fixtures in a conftest.py that can be placed anywhere within the tests folder, and should not be imported. Pytest will find those automatically and will run the fixtures during runtime.

[james-hollingsworth]

Thank you for both of your replies - I'll give these suggestions a go!

As we're currently using the TDD theme, it looks like I may need to configure Poetry slightly differently - but this looks like a great approach.