Improve Test Coverage Iteratively

Autonomously run tests, identify coverage gaps, write targeted unit tests, and repeat until both line and branch coverage reach 80% or no further improvement is possible.

When to Use

• User asks to "improve coverage", "get to 80% coverage", or "write tests for X"
• Starting an automated coverage improvement session for a class or project
• Coverage is below 80% and the user wants tests written automatically

When Not to Use

• User only wants a coverage report without writing tests — use run-coverage
• User wants to inspect a specific method's branches only — use analyze-coverage-gaps
• Project has no existing test file to append to (create one first)

Inputs

Workflow

Step 0: Setup and discover scope

1. Verify reportgenerator is installed (dotnet tool list -g); install if missing
2. Call GetSourceFiles with sourcePath and lineBudget to get:

• files — all .cs files with lines and methodCount metadata
• batches — files grouped by line budget (small files together, large files solo)
• batchCount — how many cycles to expect

Example response:

{
  "scope": "folder",
  "totalFiles": 18,
  "totalLines": 4200,
  "lineBudget": 300,
  "batchCount": 8,
  "batches": [
    [{"path": "SmallA.cs", "lines": 80}, {"path": "SmallB.cs", "lines": 120}, {"path": "SmallC.cs", "lines": 90}],
    [{"path": "BigService.cs", "lines": 920}]
  ]
}

Step 0.5: Per-batch setup (repeat for each batch)

For each file in the current batch:

1. Read the source file to understand its constructor, dependencies, and public methods
2. Check if a matching test file exists; if not, use scaffold-test-files to create one
3. Verify the test file has a [SetUp] method; add one if missing using AppendTestCode

Step 1: Run coverage for the batch (ONE test run)

Call RunTestsWithCoverage with testProjectPath and a broad filter (use * or namespace-level filter). This runs dotnet test once and collects coverage across all source files.

Leave includeClass unset. It would silently limit collection to a single class and zero out the rest of the batch.

Then for each file in the batch, call GetFileCoverage with coberturaXmlPath and the file name.

• If allMeetTarget: true → mark file as done, skip it
• If allMeetTarget: false → include in this cycle's work

Step 2: Identify lowest-coverage methods across the batch

From all non-done files in the batch, pick the 3 lowest branch-coverage methods, excluding:

• Methods already at ≥ 80% branch coverage
• Methods marked as blocked (failed 3 times with no improvement)
• Static factory methods and auto-generated property accessors

Step 3: Find uncovered branches

For each target method, call GetUncoveredBranches with coberturaXmlPath and the method name.

Note which branch conditions (branch-N-true, branch-N-false) are uncovered and what they represent.

Step 4: Write targeted tests for the batch

For each uncovered branch, write a focused unit test using AppendTestCode:

• Target one specific branch condition per test
• Max 1–3 assertions per test
• Use [TestCase] for data variations, separate [Test] methods for different mock setups
• Use insertAfterAnchor to place tests after the relevant test class or last test method
• Tests may go to different test files across the batch — that's expected

Test quality rules (strictly enforce):

• No bulk POCO tests (avoid mass property getter/setter tests with no logic)
• Behavioral focus: test calculations, conditional logic, or external interactions
• Descriptive names: MethodName_Condition_ExpectedResult pattern
• Each test must exercise a specific branch, not just increase line count

Step 4.5: Handle build/compilation errors

If RunTestsWithCoverage returns a build error after writing tests:

1. Read the error message to identify the file and line number
2. Use your standard file editing tools (Edit, Read) to fix the syntax error in the test file
3. Common causes: missing semicolon, unclosed brace, wrong type name, missing using statement
4. After fixing, re-run RunTestsWithCoverage before continuing
5. If the same test fails to compile 3 times, remove it with Edit and move on to the next uncovered branch

Do NOT call `AppendTestCode` to fix errors — use Edit to surgically fix the broken line instead.

Step 5: Re-run and check batch-level progress

Call RunTestsWithCoverage once with the same broad filter. Call GetFileCoverage for each file in the batch to check per-file progress. Call GetCoverageDiff to see method-level deltas.

For each file in the batch:

• `allMeetTarget: true` → mark as done, remove from batch
• `allMeetTarget: false` → keep in batch for next cycle

Step 6: Repeat or advance

• If batch has remaining files below 80% → return to Step 2 (same batch, fewer files)
• If all files in batch are done OR 3 cycles with no improvement → move to next batch
• If all batches complete → report final coverage summary

Termination Criteria

Performance Notes

• One `dotnet test` per cycle — not per file. This is the key optimization.
• GetFileCoverage is instant (XML parse) — call it for every file in the batch freely
• Small files (< 100 lines) get batched together so AI handles 3–5 at once
• Large files (> lineBudget) get their own batch for focused attention
• Use broad filter (* or namespace) for batch/folder/project scope
• Do NOT pass includeClass — it restricts coverage collection to one class and would zero out the rest of the batch

Validation

• [ ] GetSourceFiles returned batches grouped by line budget
• [ ] Only one RunTestsWithCoverage call per cycle (not per file)
• [ ] GetFileCoverage checked for every file in the batch after each test run
• [ ] Each test targets a specific uncovered branch (not random line coverage)
• [ ] No bulk POCO/property tests added
• [ ] Files marked done and removed from batch when they hit 80%
• [ ] Final report shows per-file and overall coverage percentages

Common Pitfalls