| name | voronoi-testing |
| description | Use when writing, updating, or running tests for voronoi. Use when any source code in src/voronoi/ is modified to ensure tests are updated. Covers test discovery, naming conventions, and verification workflow. |
Voronoi Testing Workflow
When to Use
Every time you modify code in src/voronoi/, you MUST follow this workflow.
Test File Discovery
Test files follow tests/test_{module_name}.py by convention. Non-standard mappings
(bundled test files, renamed test files) are documented in docs/SPEC-INDEX.md — always
check it before assuming a test file path.
When in doubt: run ls tests/test_*<module>*.py or grep -rl '<function_name>' tests/ to find the right file.
Workflow
After ANY code change:
-
Run the specific test file for the module you changed:
python -m pytest tests/test_<module>.py -x -q
-
Run the full suite to catch cross-module regressions:
python -m pytest tests/ -x -q
-
If tests fail: fix the code or update the test — do NOT commit with failing tests.
If you changed behavior:
- Update existing tests to match new behavior
- Add new tests for new functionality — in the same commit as the code change
Test conventions:
- Use
pytest with tmp_path fixture for filesystem tests
- Use
unittest.mock.patch for isolating dependencies
- Use
subprocess.run tests for CLI integration tests
- No runtime dependencies in tests — mock external tools (bd, copilot, docker)
- Test classes group related tests:
class TestFeatureX:
Verification Checklist
Before committing, confirm:
