Claude Code reads your coverage report, picks the riskiest untested modules and writes unit tests that pass, one small PR at a time.
Most codebases have a few critical modules with little or no test coverage, usually because they were written under deadline. Nobody wants to go back and write tests for old code, so every change to those files is a gamble. Coverage sits at the same number quarter after quarter.
Run your suite with a JSON summary reporter, for example vitest run --coverage --coverage.reporter=json-summary or jest --coverage --coverageReporters=json-summary. This writes coverage/coverage-summary.json for Claude Code to read.
Add a Testing section covering your framework, file naming (src/lib/foo.ts maps to tests/lib/foo.test.ts), how to mock the database and which helpers live in tests/utils. Claude Code reads CLAUDE.md at the start of every session.
Use the ranking prompt below to list files under 50% line coverage, sorted by how often they changed in the last 90 days. Start with the top three; frequently edited, untested code is where bugs come from.
Run the test-writing prompt in a fresh branch for each file. Claude Code writes the tests, runs them and iterates until they pass, without touching the source file.
Ask Claude Code to temporarily break one line in the source, confirm at least one new test fails, then revert. This catches tests that only assert a value is defined.
Keep each PR under 400 lines so reviewers actually read it, and request a Copilot review to spot redundant cases.
Schedule the same flow in CI with claude -p (headless mode) on one module per week, and post the before and after coverage to #engineering through a Slack incoming webhook.
Read coverage/coverage-summary.json. List every file under src/ with line coverage below {{threshold}}%.
For each file, count how many commits touched it in the last 90 days using git log --since=90.days --name-only.
Return a table sorted by commit count, highest first, with columns: file, line coverage, commits (90d), and a one-sentence note on what the file does.
Exclude generated files, type-only files and anything under src/migrations.Read {{file_path}} and any existing tests for it in {{test_dir}}. Read CLAUDE.md for our testing conventions.
Write unit tests that cover:
- the normal path of every exported function,
- edge cases: empty inputs, nulls, boundary values, very large inputs,
- every thrown error and rejected promise.
Rules:
- Do not modify {{file_path}}. If something cannot be tested without a change, stop and explain why.
- Mock only the network, database and clock. Never mock the module under test.
- Name tests in the form "returns X when Y".
- Run the tests after writing them and fix failures until they all pass.
Finish by reporting line coverage for {{file_path}} before and after.Plan, execute and review a cross-cutting refactor in small batches, with Claude Code making the edits and GitHub Copilot reviewing each PR.
Copilot and Claude review each PR for bugs, missing tests and risky changes before a human looks, so reviewers can focus on design.
Score every demo request against your ICP, update HubSpot and ping the right rep in Slack within a minute of the form submit.