Prompt Processing has a suite of unit tests for its modules.
These tests conform to DM conventions and can be run using scons or (for more precise control) pytest.
They are also run automatically on GitHub PRs, before a branch container is made.
This guide summarizes Prompt-Processing specific considerations for our unit tests.
In particular, tests of the middleware_interface module need to simulate our division of data into central and local repos.
Several test suites, particularly test_middleware_interface.py, test repository management functionality and need a suitable Butler repository.
This repository is at tests/data/central_repo/, and includes a minimal set of calibration and reference datasets.
The repository can be regenerated by calling tests/data/make_central_repo.sh (at least in principle; in practice, it’s prone to bit rot).
Most of the datasets in the test repository have been replaced by empty files to save disk space, so this package doesn’t need to use Git LFS. However, this also means that unit tests must never actually read ordinary datasets, though they can test for their presence or inspect metadata. The only non-empty files are the Butler registry, camera, and skymap, which are too fundamental to safely mock out.
We also have a complete central repository for integration tests.
That repository is described in the Playbook, though some of the scripts in bin.src/ and etc/ are used to maintain it.
Prompt Processing’s unit tests must be runnable in the standard Rubin development environment (rubin-devl).
However, Prompt Processing’s base container adds libraries that are not part of rubin-devl, such as Prometheus and Redis.
These dependencies break unit tests, though they can still be used during integration testing.
The non-standard packages are used exclusively by activator/driver_keda.py and activator/driver_gunicorn.py, making these two modules impossible to import in the rubin-devl environment.
All other modules are testable.
To maximize our test coverage, avoid putting anything in driver_* that doesn’t require one of these external packages.
This also helps keep these modules focused on a specific purpose; see Package Organization for the desired separation of concerns.
Several components in activator/activator.py haven’t been tested because they also depend on third-party packages like S3.
These dependencies are available in rubin-devl and can be imported, but for various reasons it’s difficult to write oracles for them (for example, S3 never specs the type or even the structure of its messages).
These test gaps are marked with TODO comments in test_activator.py, and filling them is highly encouraged.