Testing and benchmarks
Install the test environment
make install
make check
make install installs the core and all five local add-on projects in editable mode, plus the test and docs tools. The test requirements pin pydantic-settings-extra-sources==0.1.0 for live configuration parity checks. It is not a runtime dependency.
make check runs tox's supported Python environments (py311 through py314) and the formatting, lint, strict type, and docs-build environments. Tox skips interpreters that are not installed locally; CI selects each Python environment explicitly so every supported version is exercised. Run one Python environment with tox run -e py312, or the non-matrix checks with tox run -e lint,type,docs.
The package metadata keeps each runtime integration independent. The Testcontainers suite builds the core and all five add-on wheels, then resolves the core, each single extra, and the combined extras in clean Python containers. It checks that unselected integrations stay absent:
| Install target | Checkout equivalent | Expected optional packages |
|---|---|---|
standard |
. |
None |
standard[fastapi] |
-e . -e packages/standard-fastapi |
standard-fastapi and FastAPI |
standard[aws] |
-e . -e packages/standard-aws |
standard-aws and boto3 |
standard[http] |
-e . -e packages/standard-http |
standard-http and HTTPX |
standard[cache] |
-e . -e packages/standard-cache |
standard-cache and Redis |
standard[rdbms] |
-e . -e packages/standard-rdbms |
standard-rdbms, SQLAlchemy, and async drivers |
standard[fastapi,aws,http,cache,rdbms] |
Core plus all five local add-on projects | All add-on distributions and their dependencies |
The latest coordinated release is v0.2.4; all six distributions use version
0.2.4. The repository's Testcontainers suite validates built wheels and
clean consumer installs from the current source. The independent example in
sample-projects/standard-fastapi-consumer
adds an application-level check of the public API and project conventions.
These checks establish only the behaviors and environments they exercise; they
do not prove every possible application setup.
On 2026-10-13, I downloaded the six published 0.2.3 wheels and installed
them into isolated CPython 3.12 virtual environments. Core-only, each single
extra, and all extras together passed pip check. Core-only did not expose
provider namespaces; each single extra exposed only its selected namespace;
the combined install exposed all five. std --version reported std 0.2.3,
and std guide --format json returned schema version 1. This historical
smoke check covers package metadata, imports, and CLI startup, not external
service behavior.
The 0.2.3 core wheel also exposed a stale packaged-skill statement that
called std.service unreleased. This was fixed in 0.2.4 and is guarded by
source and built-wheel regression tests. On 2026-10-13, a fresh CPython 3.12.11
consumer environment installed standard[fastapi]==0.2.4 from PyPI. pip
check passed; std --version reported std 0.2.4; the JSON guide listed
std.service as core and std.fastapi as extra:fastapi; and the installed
skill contained the std.service guidance without the stale unreleased claim.
The full sample check passed: four tests, Ruff format and lint, and strict
mypy. See the consumer evaluation
for exact commands and scope.
The v0.2.4 tag published all six distributions, each with a wheel and source
archive. The GitHub release
contains the artifacts and SHA256SUMS. The release workflow run
completed the preflight, build, PyPI publish, attestation, and GitHub release
jobs successfully. This artifact smoke check covers metadata, imports, CLI,
and the installed skill; it does not replace the Testcontainers service tests.
Layers
| Layer | What it proves | Likely tools |
|---|---|---|
| Unit | Parsing, merge, interpolation, immutable snapshots, reload, sources, helpers, CLI, and redaction. | pytest |
| Integration | FastAPI dependency, AWS source, HTTP request/auth, and Redis command behavior with injected or local clients. | pytest, optional extras |
| Container end-to-end | Built wheel install, mounted YAML/TOML consumer, Redis behavior, relational database transactions, and LocalStack AWS operations. | Testcontainers for Python |
| Compatibility | YAML and TOML values, interpolation, YAML directory merge, and source precedence compared with the live reference package. | tests/parity/ |
| Performance | Load, lookup, directory merge, reload, and peak memory with correctness checked first. | benchmarks/configuration.py |
Container scenario
tests/integration/test_consumer_container.py builds six wheels, installs the core alone, each single extra, and all five extras into separate python:3.12-slim containers, mounts YAML and TOML files, injects an environment value for YAML interpolation, and exercises both Pydantic Settings adapters plus installed provider APIs. Other container tests cover Redis, SQLite lifecycle behavior, PostgreSQL, MySQL, and LocalStack.
The E2E workspace is created inside the repository so Docker VMs that share the checkout can read the bind-mounted wheel and settings files; pytest removes it after the session. The E2E tox environment passes through STD_REQUIRE_DOCKER and the Testcontainers runtime overrides. GitHub Actions runs the suite with the default Ryuk cleanup helper.
The E2E test requires a working Docker socket. Locally, run make test-e2e and ensure Docker is running. If Rancher Desktop cannot start Ryuk, this local command disables only Ryuk; each tested container is still stopped by its context manager:
STD_REQUIRE_DOCKER=1 \
TESTCONTAINERS_RYUK_DISABLED=true \
TESTCONTAINERS_DOCKER_SOCKET_OVERRIDE=/var/run/docker.sock \
tox run -e e2e
Verification status and release gates
On 2026-10-13, make check passed on Linux with CPython 3.12.11: 248 tests
passed, 11 E2E tests were deselected, coverage was 94%, and Ruff, strict mypy,
and the clean docs build passed. Tox skipped CPython 3.11, 3.13, and 3.14
because those interpreters were not installed locally. make test-e2e then
passed all 11 Testcontainers cases in 109.95 seconds. These results apply to
the current checkout and environment; they do not claim cross-platform or
all-interpreter coverage.
CI is configured for CPython 3.11–3.14, lint, strict typing, documentation
build, and Testcontainers end-to-end checks. The release workflow requires a
successful main CI run for the exact tagged commit before it publishes all
six distributions. For hosted evidence tied to a specific revision, inspect
the CI workflow runs
and release workflow runs.
Workflow configuration describes intended checks; a passing run is the
evidence for a particular commit.
The configured release checks cover:
- Unit and contract cases for missing sources, directory order, empty defaults, JSON-looking strings, interpolation cycles, YAML aliases, and secret redaction.
- A live parity case for ordinary reference behavior outside the fixes recorded in the configuration contract.
- A Testcontainers consumer scenario that uses the same public API installed users call.
- Ruff formatting, lint and public docstring checks, strict mypy, coverage, and a clean documentation build.
- Benchmark correctness checks before timing and retention of the raw measurement file.
Benchmark command
make bench
The benchmark emits JSON to benchmarks/results/ and prints environment identity. It does not claim a 100× improvement; compare the recorded workload and measurements before making any performance statement.