Coverage: ranked plan to move workspace coverage toward 90%

[karthiknadig]

Summary

Coverage reporting is now in place, but the current test distribution makes 90%+ workspace coverage unrealistic without a targeted backlog. This issue proposes a ranked coverage plan based on the current crate-by-crate test footprint and source size.

Why 90% is not realistic today

From a local inventory of workspace source and tests:

• Total Rust source lines under crates/*/src: about 17,466
• Source lines in crates with no test footprint at all: about 2,450
• That alone implies a rough workspace ceiling of about 85.97% if those crates remain near 0%
• Source lines in crates with a very sparse test footprint (3 or fewer test markers/files): about 3,493 or roughly 20% of workspace source

Coverage is being measured in .github/workflows/coverage.yml, but there is currently no fail-under-* gate, so the workflow reports coverage drift without forcing the repo upward.

Main gaps

Completely untested crates

Ordered roughly by impact:

1. pet-windows-store (~431 lines)
2. pet-reporter (~340 lines)
3. pet-windows-registry (~310 lines)
4. pet-mac-commandlinetools (~224 lines)
5. pet-mac-xcode (~209 lines)
6. pet-linux-global-python (~206 lines)
7. pet-jsonrpc (~197 lines)
8. pet-virtualenvwrapper (~178 lines)
9. pet-mac-python-org (~153 lines)
10. pet-global-virtualenvs (~79 lines)
11. pet-pixi (~74 lines)
12. pet-env-var-path (~49 lines)

Lightly tested crates

These crates have some tests, but not enough relative to their size:

1. pet-homebrew (~612 lines, only 1 inline test marker)
2. pet-pyenv (~431 lines, only 2 integration test files)
3. pet main crate (~2147 lines, tests are mostly happy-path CLI and CI discovery validation)

Ranked plan

Phase 1: Fastest coverage lift from deterministic unit tests

Target the coordination and parsing crates first because they are small-to-medium sized and do not need heavy external environment setup.

1. Add direct unit tests for pet-jsonrpc
   • Cover get_content_length
   • Cover request vs notification routing
   • Cover unknown method handling
   • Cover malformed payload handling
2. Add direct unit tests for pet-reporter
   • collect reporter accumulation
   • cache reporter behavior
   • stdio/jsonrpc reporter output formatting where feasible
3. Add focused tests for small utility crates with zero coverage
   • pet-env-var-path
   • pet-global-virtualenvs
   • pet-pixi
   • pet-virtualenvwrapper

Expected outcome: a meaningful coverage increase with low platform complexity.

Phase 2: Fill the biggest untested Windows-specific holes

These crates are large enough to matter, and Windows coverage already exists in CI.

1. Add tests for pet-windows-store
   • path normalization and matching
   • cache behavior
   • environment identification from discovered symlinks
2. Add tests for pet-windows-registry
   • registry record parsing
   • environment construction
   • negative cases and malformed entries

Expected outcome: another large step up in the Windows half of the coverage report.

Phase 3: Improve Linux/global and Homebrew coverage

1. Expand pet-homebrew beyond version extraction
   • locator identification
   • non-homebrew rejection
   • symlink / prefix handling
2. Add tests for pet-linux-global-python
   • /usr/bin, /usr/local/bin, and rejection cases
3. Add more branch-focused tests to pet-pyenv
   • manager discovery variants
   • fallback paths
   • negative identification cases

Expected outcome: better coverage on the non-Windows path and less reliance on broad end-to-end tests.

Phase 4: Add direct tests for macOS locators

These crates are not exercised by the current Linux/Windows coverage matrix and will likely need fixture-heavy unit tests rather than full CI environment setup.

1. pet-mac-commandlinetools
2. pet-mac-xcode
3. pet-mac-python-org

Focus on pure identification logic and symlink/prefix derivation using fixtures and synthetic paths.

Expected outcome: better local confidence and clearer path to adding a macOS coverage job later if desired.

Phase 5: Strengthen the main pet crate around error paths

The main crate already has CLI and CI tests, but most are discovery validation rather than branch coverage.

1. Add targeted tests for jsonrpc request handling
2. Add tests for configure / refresh malformed input and edge cases
3. Add tests for search-path expansion behavior
4. Add tests for fallback identification and unknown-environment reporting
5. Add tests for refresh locking / serialization behavior where practical

Expected outcome: better coverage in the orchestration layer, where many user-facing regressions land.

Phase 6: Only then add a coverage gate

After the biggest gaps above are closed:

1. Add fail-under-lines and possibly fail-under-functions to the coverage workflow
2. Start with a realistic threshold, not 90 immediately
3. Raise it incrementally as phases land

Suggested progression:

1. Start with a threshold near the current measured baseline
2. Raise after Phase 1 and Phase 2 land
3. Revisit whether 90% is realistic after Phase 4 and Phase 5

Recommended order of implementation

1. pet-jsonrpc
2. pet-reporter
3. pet-windows-store
4. pet-windows-registry
5. pet-homebrew
6. pet-linux-global-python
7. pet-pyenv
8. pet-virtualenvwrapper
9. pet-pixi
10. pet-env-var-path
11. pet-global-virtualenvs
12. macOS locator crates
13. pet main-crate error-path tests
14. coverage threshold in CI

Acceptance criteria

• Add unit/integration tests for pet-jsonrpc
• Add tests for pet-reporter
• Add tests for pet-windows-store
• Add tests for pet-windows-registry
• Expand pet-homebrew coverage beyond version parsing
• Add tests for pet-linux-global-python
• Expand pet-pyenv branch coverage
• Add tests for pet-virtualenvwrapper
• Add tests for pet-pixi
• Add tests for pet-env-var-path
• Add tests for pet-global-virtualenvs
• Add direct tests for macOS locator crates
• Add error-path tests in pet
• Add a staged fail-under-* coverage gate in CI

Notes

There was already a closed issue to add coverage reporting itself: #305. This issue is specifically the follow-up plan for raising actual code coverage in a ranked, low-risk order.