Published Coverage Differs from VSTest Coverage Report

SonarQube Cloud
, ,
2

Hi @BDRichardson,

A couple of things going on here:

  1. You’re comparing two different scopes. The 50% figure is SonarQube’s Coverage on New Code, it only looks at the 2 lines flagged as new/changed in this analysis (1 of 2
    covered = 50%). The 64.48% from VSTest is coverage across the entire assembly (256/397 lines). These numbers aren’t meant to match, see SonarQube and code coverage for why comparing a tool’s raw report to SonarQube’s published metric is often misleading, and the New Code docs for how the New Code scope is defined.

  2. The “only 2 new lines” number seems a bit weird here.
    You mentioned unchanged lines are being reported as new, and the logs show that:
    Incremental PR analysis: Base branch parameter was not provided, Cache data is empty. A full analysis will be performed., and a blank merge-base SHA1. That points to the SCM diff not resolving the target/base branch correctly, which would explain why the new-code line count looks so small and may be wrong.

To narrow this down:

  • Is this pipeline run configured as a PR build (with PR.TargetBranch etc. set), or is it
    analyzing the branch standalone? The “base branch parameter was not provided” line
    suggests SonarQube didn’t get PR context.
  • Can you confirm the checkout step does a full git fetch (not shallow, and with enough
    history to reach the merge base)? A shallow/partial clone is a common cause of “unchanged lines counted as new.”
  • What is your project’s New Code definition (previous version / number of days /
    reference branch)?

If you can share the full analysis log around the “SCM Publisher” section, we can confirm
whether it’s actually finding the correct changed-lines diff.

Cheers,

Stevan