Testing

Running tests

uv run pytest -q

uv run --with build python -m build --sdist --wheel
uv run --with twine python -m twine check dist/*

The repository includes committed unit tests. Dataset-backed parity tests are kept in-tree as optional checks and skip cleanly when the local validation datasets are absent, so uv run pytest -q remains the clean-checkout gate.

Release wheel production is separate from the smoke-build command and uses cibuildwheel on the release hosts.

Test structure

Default unit tests cover config loading, dataset discovery, acceleration helpers, and Stage-7 helper math.
Dataset-backed parity tests and audits require local inputs under inputs_and_outputs/ and are not part of the minimal fresh-clone contract.
Parity checks are documented in the verification guide so you can keep the test command list focused.

Coverage

Validation starts with uv run pytest -q, uv run --with build python -m build --sdist --wheel, and uv run --with twine python -m twine check dist/*, then moves to parity-audit validation in Verification.

For PyPI wheel releases, use uv run --with cibuildwheel python -m cibuildwheel --platform ... --output-dir dist on the Linux, macOS, and Windows release hosts.

For parity workflows, do not guess a Makefile, CI wrapper, or reduced audit dataset list. Use the documented audited dataset set, the generated latest_audit.json, and the explicit verify command shape.

In-code assertions and explicit exceptions define many behavior guarantees where test coverage is expected to assert failure conditions.

Validation workflow

Parity audits and explicit verify command patterns are described in Verification.

The verification flow includes contract construction, script orchestration, and CLI comparison commands used by release quality checks.

uv run pystamps verify --run RUN_COPY --golden ./inputs_and_outputs/InSAR_dataset_test

Carry the fresh run_root from latest_audit.json into that verify step; stale-output reuse keeps the validation gate red.