Patterns for Python integration tests (e.g. w/ Postgres database)

[peter-woyzbun]

I have some Django applications I am looking to onboard to a monorepo that uses Pants. These applications depend on Postgres-specific database features, e.g. triggers, and so tests require a running Postgres database (vs. just using SQLite). Ideally these tests could run within Pants/hermetically - i.e. without having to run something like docker-compose locally before running pants test :: (and equivalent in GitHub workflows/CI) to make a Postgres database available.

Does this seem generally possible? Is there any official stance on support (or planned support) for patterns like this? My first thought was that Pants has support for running Docker images, and for running Python tests, so maybe a plugin would work. The idea would be to have something like:

python_tests(
    dependencies = [
        ":test_utils",
    ],
    extra_env_vars = [
        "DJANGO_SETTINGS_MODULE=tests.django_settings",
        "DATABASE": "my-database"
    ],
    docker_services=[
        {"image": "<registry>/postgres:15.8", "docker_env": {"POSTGRES_DB": "my-database"}, "run_args": "...", "port": 5432}
    ]
) 

with the complications being that:

1. Port mappings from the host to the running container would likely need to be dynamic, to prevent port clashes between parallel test runs from multiple python_tests targets requiring docker_services (e.g. if I have two python_tests targets, both requiring a Postgres database, we might need two databases running in parallel).
2. The Docker services would need to be running before tests start to run, and then torn down afterwards.

Any guidance or suggestions on how to support these types of integration tests would be appreciated.

[salotz]

This is a massive amount of work and I would imagine it is probably outside of the scope of Pants core. In my organization we use a separate tool for what you are describing, lets call them integration tests.
Our tool (garden) oriented for Kubernetes but does a great job of what you are describing but also way more complex use cases.

I think there are opportunities for integrating these different kinds of tools, but they can be used in harmony together today. For instance I would use garden to set up the testing environment and then pants inside the container to run the tests and it can then efficiently only run tests for the effected modules.

On the other hand we might use Pants to tell Garden which integration test jobs need rerun from doing a dependency analysis, via a Pants plugin.

Hope some of my experience helped.

[peter-woyzbun]

Thanks for your response. Interesting looking tool but a bit much for what we need at the moment. I ended up finding a solution that uses a docker_environment target to run the tests in a container with Postgres installed.

[peter-woyzbun]

What I ended up doing is using a docker_environment target harnessing a Docker image with Postgres installed. In my Python unit tests I can then use pytest-postgresql (https://github.com/dbfixtures/pytest-postgresql), which will use a subprocess to spin up a Postgres database for each test session.

python_tests(
    # Will run tests within Docker container with Postgres installed
    environment = "py311_postgres",
    # Will make sure environment Docker image is built before running tests
    runtime_package_dependencies = ["//docker-envs/py311-postgres:image"],
    # Run tests in a single batch so we don't need multiple Postgres processes/instances
    batch_compatibility_tag = "postgres-db",
    ...
)