Cloud Parts

Test environment managers

Run the same suite in several isolated environments, one per interpreter or dependency version, from one config file.

How they work

A Python library usually promises to work on several Python versions and with a range of dependency versions. An environment manager turns each combination into a named environment. For each one, tox creates a fresh virtual environment for the matching interpreter, installs the dependencies, builds the project and installs it like a user would, runs the commands, and reports. It exits with 0 only if every environment passed, and it reuses environments on the next run unless the dependencies change.

Matrices keep the config short: a product of factors, such as Python 3.12, 3.13 and 3.14 times Django 4.2 and 5.0, expands to six environments. The same machinery runs non-test jobs too, such as a lint or docs environment. nox does the same job with a Python file of “sessions” instead of a declarative config, and Hatch defines a test matrix for its built-in test environment.

On a small suite, setting up environments takes most of the run time. Both tools can hand that work to uv: the tox-uv plugin replaces virtualenv and pip with uv (with, its README warns, both uv’s speed and its bugs), and nox ships a uv backend. An application that ships on one pinned version gains less: one environment, in CI, is often enough.

Technologies

What all automated testing have in common →

Sources

Improve this page on GitHub