voronoi-testing

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:

1. Run the specific test file for the module you changed:

   python -m pytest tests/test_<module>.py -x -q
   

2. Run the full suite to catch cross-module regressions:

   python -m pytest tests/ -x -q
   

3. If tests fail: fix the code or update the test — do NOT commit with failing tests.

If you changed behavior:

4. Update existing tests to match new behavior
5. 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:

• Specific module tests pass
• Full test suite passes (all green)
• New behavior has corresponding test coverage
• No test depends on external services or network