dancing-bear: Skill for Claude Code

Expand Coverage

Find coverage gaps, write tests, and verify improvement.

When to Use

• After writing new code that needs tests
• User says "add tests" or "improve coverage"
• Coverage below 80% on new/changed files
• As part of /review-fix Phase 2

Step 1: Identify Gaps

# Full coverage report (all domains)
make cov

# Coverage for a specific domain
PYTHONPATH="$PWD/src" python3 -m coverage run -m unittest discover -s tests/<domain>_tests -t . -q
PYTHONPATH="$PWD/src" python3 -m coverage report -m --include="src/<domain>/*"

# Lint-level complexity/smell signals (not coverage, but flags files needing tests)
~/.qlty/bin/qlty check src/<domain>/

Step 2: Prioritize

Order by impact:

1. New files with 0% coverage — need test skeletons
2. Changed files below 80% — need gap tests
3. Critical paths below 90% — auth, credentials, API clients

Step 3: Write Tests

For each file needing coverage:

1. Read the source to understand what to test
2. Read the shared test helpers for available factories, fakes and mixins. This is a stdlib unittest suite: there are no conftest.py files and no tests/helpers/ package.
   • tests/fixtures.py — cross-domain helpers (TempDirMixin, temp_yaml_file, capture_stdout, write_csv, …)
   • tests/<domain>_tests/fixtures.py — domain factories. Some domains name it shared_fixtures.py (qlty, telemetry, wifi) or helpers.py (worker); ls the directory first
   • tests/fakes/ — offline Gmail, Outlook and DOCX fakes
   • tests/*_contract.py — shared CLI and agentic contract mixins; subclass them rather than re-asserting
3. Write tests following project conventions

Test Conventions (Mandatory)

• Use the make_* factories in those fixture files, never construct dicts manually
• Reuse constants the domain's fixtures module already defines rather than new literals
• Patch where the name is used, not where it's defined
• Specific assertions: assertEqual, assertIn, assertIsInstance
• @dataclass for test fixtures