| name | test-coverage |
| description | Analyze test coverage and identify gaps. Run tests, identify modules without tests, and suggest specific functions that need test coverage.
|
Test Coverage Skill
Analyze test coverage and identify modules needing tests.
Steps
-
Run all tests and collect results
cargo test 2>&1
Note total test count and any failures.
-
Identify modules without tests
Search for Rust source files and check for #[cfg(test)] blocks:
for f in src/**/*.rs; do
if ! grep -q '#\[cfg(test)\]' "$f" 2>/dev/null; then
echo "$f"
fi
done
-
Analyze untested modules
For each untested module, identify:
- Public functions that should have unit tests
- Complex logic that would benefit from testing
- Edge cases in the implementation
-
Generate coverage report
Report modules by priority:
- Critical: Core logic (session management, state transitions)
- High: Input handling, navigation logic
- Medium: Utility functions, helpers
- Low: Simple structs, trivial implementations
Coverage Categories
Modules that SHOULD have tests
- State management (
app/state.rs, session/mod.rs)
- Business logic (filters, calculations, validations)
- Type conversions and parsing
- Navigation and routing logic
Modules that MAY skip tests
- Pure TUI rendering (requires integration testing)
- PTY interaction (requires real terminal)
- Simple re-exports and type aliases
Example Report
Test Coverage Report:
Total tests: 261
Modules with tests: 26/42 (62%)
High Priority Gaps:
- src/input/dispatcher.rs - No direct tests (routes to handlers)
- src/input/session_mode.rs - No tests (PTY interaction)
Medium Priority Gaps:
- src/tui/views/*.rs - Rendering modules (integration tests recommended)
Coverage by Area:
- Core (app, session, hooks): 80%
- Input handling: 40%
- TUI rendering: 20%
- Utilities: 90%
Suggestions
After running this skill, consider:
- Adding unit tests to high-priority gaps
- Creating integration test scaffolding for TUI tests
- Adding property-based tests for parsing/filtering logic
