Coverage, Honestly

Code coverage measures which lines of your code ran while the tests ran. That is the whole mechanism. The tool instruments the assemblies, records what was executed, and divides.

Read that definition again, because the gap between it and how coverage gets used is the subject of this lesson. Coverage does not measure whether anything was checked. It cannot distinguish a line that ran under a precise assertion from a line that ran inside a test with no assertions at all.

It is still worth collecting. Uncovered code is a genuine fact — nothing you have written exercises it — and that fact is often the fastest way to find a rule nobody tested. The failure is treating the percentage as a measure of quality.

# Add the collector to the test project, once
dotnet add Ordering.Domain.Tests package coverlet.collector

# Run the suite and produce a coverage file
dotnet test --collect:"XPlat Code Coverage"

# Turn the raw file into something readable
dotnet tool install --global dotnet-reportgenerator-globaltool
reportgenerator -reports:**/coverage.cobertura.xml -targetdir:coverage -reporttypes:Html

# Then open coverage/index.html and read the uncovered lines,
# not the number at the top

• The collector runs inside dotnet test and writes a Cobertura XML file per test project under TestResults.
• That file is not meant for people. The report generator turns it into HTML where each source file is shown with covered and uncovered lines marked, which is the view that is actually useful.
• The last comment is the point of the whole exercise. The summary percentage is the least informative thing in the report; the list of uncovered lines is where the information is.
• In a pipeline, publish the HTML report as an artefact. A number in the log gets glanced at once; a browsable report gets used when somebody is deciding what to test next.

public decimal ApplyDiscount(decimal price, int percentage)
{
    if (percentage < 0 || percentage > 100)
    {
        throw new ArgumentOutOfRangeException(nameof(percentage));
    }

    decimal reduction = price * percentage / 100m;
    return decimal.Round(price - reduction, 2);
}

// -- Test A: covers every line of the happy path. Verifies nothing.
[Fact]
public void ApplyDiscount_Runs()
{
    var calculator = new PriceCalculator();
    calculator.ApplyDiscount(100m, 20);
}

// -- Test B: same lines, and it would fail if the answer were wrong.
[Fact]
public void ApplyDiscount_WithTwentyPercentOffOneHundred_ReturnsEighty()
{
    var calculator = new PriceCalculator();

    decimal result = calculator.ApplyDiscount(100m, 20);

    Assert.Equal(80m, result);
}

• Both tests execute the same lines, so both report the same coverage for this method. The tool has no way to see the difference, because assertions are not part of what it measures.
• Test A passes for any implementation that does not throw. Return the price unchanged, return zero, return a random number — still green, still counted as covered.
• This is not a hypothetical. Tests written to raise a coverage number look exactly like Test A, because that is the shortest route to the number.
• Note also what neither test covers: the guard clause. Line coverage for the method is high while the branch that rejects bad input has never run — which is the gap branch coverage exists to show you.