Coverage Analysis

Coverage Analysis

Purpose

Raw coverage percentages answer "what code was executed?" — they don't answer what you actually need to know:

• What tests should I write next? — ranked by risk and impact
• Which uncovered code is risky vs. trivial? — CRAP scores separate the two
• Why has coverage plateaued? — identify the files blocking further gains
• Is this code safe to refactor? — complex + uncovered = dangerous to change

This skill bridges that gap: from a bare .NET solution to a prioritized risk hotspot list, with no manual tool configuration required.

When to Use

Use this skill when the user mentions test coverage, coverage gaps, code risk, CRAP scores, where to add tests, why coverage plateaued, or wants to know which code is safest to refactor — even if they don't explicitly say "coverage analysis".

When Not to Use

• Targeted single-method CRAP analysis — use the crap-score skill instead
• Writing or generating tests — this skill identifies where tests are needed, not write them
• General test execution unrelated to coverage or CRAP analysis
• Coverage reporting without CRAP context — use dotnet test with coverage collection directly

Inputs

Prerequisites

• .NET SDK installed (dotnet on PATH)
• At least one test project referencing the production code (xUnit, NUnit, or MSTest) — only required for the from-scratch path; not needed when the user supplies an existing Cobertura XML
• Optional, only for the from-scratch path: internet/NuGet access for dotnet add package coverlet.collector (or Microsoft.Testing.Extensions.CodeCoverage) when a test project has no coverage provider yet. Skip when the user supplies an existing Cobertura XML.
• Optional, only for Phase 5: internet access for dotnet tool install (ReportGenerator). Core CRAP/coverage analysis works from Cobertura XML alone — ReportGenerator only adds HTML/CSV reports as an optional post-summary extra.