In order to support various projects and environments in which tests might be run, each docker-based fixture has the ability to customize its default configuration.
The precedence of the available config mechanisms follow the order:
In general we would only recommend use of the environment variable config for temporary changes to a value, or for configuration that is specific to the environment in which it is being run.
A common use case for this mechanism is local port conflicts. When a container is started up, we bind to a pre-specified port for that resource kind. We (attempt to) avoid conflicts by binding to a non-standard port for that resource by default, but conflicts can still happen
All configuration options for the given resource are available under env vars named in the pattern:
Resource is the name of the resource, i.e. POSTGRES, MONGO, REDIS, etc
CONFIG is the name of the config name. Every container will support at least: IMAGE, HOST, PORT, and CI_PORT.
In general, we recommend fixture configuration for persistent configuration that is an attribute of the project itself, rather than the environment in which the project is being run.
The most common example of this will be
image. If you’re running postgres:8.0.0 in production,
you should not be testing with our default image version! Other resource-specific configurations,
root_database, might also be typical uses of this mechanism.
Here, the pattern is by defining a fixture in the following pattern:
pmr_postgres_config, returning a
PostgresConfig type. might look like
from pytest_mock_resources import PostgresConfig
Default configuration uses the same mechanism (i.e. fixture configuration) as you might, to pre-specify the default options, so that the plugin can usually be used as-is with no configuration.
The configuration defaults should not be assumed to be static/part of the API (and typically changes should be irrelevant to most users).
See the API docs for details on the current defaults.