Test coverage detector reports 0% despite 117 passing tests in __tests__ directories

[peteromallet]

Problem

When scanning a TypeScript project with 15 test files (117 tests) in __tests__ subdirectories, the test coverage detector reports 0% test health and "no test files found" for every production module.

Reproduction

Project: /Users/peteromalley/Documents/personal_website

Test files are correctly classified in the test zone (verified with desloppify zone show):

src/__tests__/App.test.tsx
src/components/__tests__/Header.test.tsx
src/lib/__tests__/markdown.test.ts
... (16 test files total)

All tests pass: npx vitest run → 15 files, 117 tests passed.

But desloppify scan reports:

Test health: 0.0%
test coverage: 45 issues (untested module)

Investigation

The matching functions work correctly in isolation:

from desloppify.languages.typescript.test_coverage import map_test_to_source, resolve_import_spec

prod = {'src/components/Header.tsx'}
map_test_to_source('src/components/__tests__/Header.test.tsx', prod)
# Returns: 'src/components/Header.tsx' ✓

resolve_import_spec('../Header', 'src/components/__tests__/Header.test.tsx', prod)
# Returns: 'src/components/Header.tsx' ✓

naming_based_mapping() also works:

naming_based_mapping(test_files, prod_files, 'typescript')
# Returns all 9 production files matched ✓

The bug appears to be upstream — either the test files aren't being passed to the matching functions during a real scan, or the import graph construction isn't including the test files, causing the early if not test_files check to short-circuit at detector.py:52.

Expected behavior

Test coverage detector should recognize __tests__ subdirectory test files and match them to their production counterparts, reporting accurate test coverage.

Environment

• desloppify from local source at /Users/peteromalley/Documents/desloppify
• TypeScript project with vitest, React, Express SSR
• macOS Darwin 24.4.0

[peteromallet]

Update: Detection logic works in isolation

Further investigation shows the matching functions work correctly end-to-end when called manually:

Production: 77, Test: 16
Tested by imports: 16
Tested by naming: 11
Total tested: 16

16 production files are correctly matched to test files via import-based mapping. The build_dep_graph includes test files, _normalize_graph_paths correctly relativizes them, and both import_based_mapping and naming_based_mapping return correct results.

The bug is in the scanner orchestration layer, not the detection logic. Specifically, somewhere between phase_test_coverage() in shared_phases_review.py and the actual detect_test_coverage() call, either:

1. The zone_map passed to detect_test_coverage doesn't include the test files (possibly built from a different file set than the dep graph)
2. The graph passed is empty or doesn't contain test file entries
3. The test_files set from zone_map.include_only(all_files, Zone.TEST) returns empty because zone rules don't match

The zone classification IS correct per desloppify zone show output. So the most likely cause is a mismatch between the zone_map.all_files() file set and the actual files on disk — the zone map may be built from a cached or stale file list that predates the test files being created.

Reproduction path: Run desloppify scan --path . in a TypeScript project that has test files in __tests__/ subdirectories. The scan reports 0% test health even though desloppify zone show correctly classifies the test files.

[peteromallet]

Investigated this thoroughly — I can't reproduce on the current codebase (0.9.14-dev). Scanning your personal_website project gives 33.3% test health with all 16 test files correctly classified in the test zone.

Several test coverage fixes have shipped since 0.9.12 (when you filed this), so the underlying issue may already be resolved.

I did harden one fragile code path: _normalize_graph_paths was only sampling the first 3 graph keys to decide whether normalization was needed — now it checks all keys (commit a64c17e).

Can you reproduce this on the current code? If so, I'd like to see the exact commands and any .desloppify/state-typescript.json that shows 0%.

[peteromallet]

Thanks for investigating. The _normalize_graph_paths sampling fix (a64c17e) is likely the root cause — if the first 3 keys in the dict happened to be relative (e.g., production files resolved before test files), it would skip normalization entirely, leaving the remaining absolute-path test file entries unmatched against the relative-path production set.

I'll update to 0.9.14-dev and re-test. If 33.3% test health shows up, consider this resolved.