Removing [ExcludeFromCodeCoverage] attribute does not update coverage history correctly

SonarQube Server / Community Build
, , ,
1

Must-share information (formatted with Markdown):

which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)

9.9.0.65466

how is SonarQube deployed: zip, Docker, Helm

I believe it is in an Azure App Service via Docker.

what are you trying to achieve

In C#, we had some classes with the [System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverage] attribute. We removed the attribute and pushed an update. Now we’re making changes to that class, and adding unit tests, but that file is not listed in the coverage report after our pipelines run.

what have you tried so far to achieve this

Tried creating a fresh branch and re-implementing the changes in case the git history somehow was incorrect.

Tried rebasing the branch onto main to make sure the git history was linear.

The main branch lists that class with 0% code coverage now (expected). But the new pull request does not include that file in it’s coverage report at all.

Please let me know if I can clarify anything, thank you.

Edit: I added some more details in the first reply below.

2

Goal

I am attempting to accurately measure code coverage for a C# solution with a pipeline in an Azure DevOps repository. The solution has undergone changes, including removal of System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverage attribute from a class called MyClass, and addition of unit tests for it. However, the SonarQube Quality Gate report for the pull request on the feature/my-class branch is not including MyClass in its code coverage report, despite the attribute being removed and the main branch having been analyzed by SonarQube without the attribute. I want to ensure that the code coverage for MyClass is accurately reported in the pull request.

What I have tried so far:

  • the first branch with our changes feature/my-class (the git history may be confusing because this branch was created before main branch was updated to remove the ExcludeFromCodeCoverageAttribute - but there were no merge conflicts)
  • I checked out a new branch from feature/my-class and then did git rebase main
  • I checked out a new branch from main, and then just copy/pasted all of the changes from feature/my-class and pushed them in one commit

Additional Notes:

  • The main branch, which no longer has the ExcludeFromCodeCoverage attribute, shows 0% code coverage as expected due to lack of unit tests and incomplete implementation.
  • The feature/my-class branch includes MyClass implementation and corresponding unit tests with about 45% code coverage in local Visual Studio.
  • Despite these efforts, the SonarQube Quality Gate report for the pull request on feature/my-class branch does not include MyClass in its code coverage analysis, behaving as if the ExcludeFromCodeCoverage attribute is still present. This is inconsistent with the actual state of the code.

Note to the Sonar Community

I am facing an issue with SonarQube code coverage analysis in a C# solution with specific changes made to a class (MyClass).

Despite removing the System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverage attribute and adding unit tests, the code coverage report for the pull request on the feature/my-class branch is not including MyClass in its analysis.

The main branch, without the attribute, displays 0% coverage as expected. I’ve attempted various solutions including rebasing and recreating branches, but the issue persists.

Any insights or guidance on resolving this discrepancy would be greatly appreciated. Thank you!

3

I’m starting to think the ExcludeFromCodeCoverage has nothing to do with this, but our SQ cache might just need to be cleared.

4

Hi,

Welcome to the community!

This is external to SonarQube and analysis. SonarQube simply reads the coverage reports you pass in. Files missing from your coverage report are a bit out of scope for us.

We don’t work from these attributes; only from your coverage reports and any coverage exclusions you’ve set on the SonarQube side.

This is unlikely. While we do cache information for issue detection for reuse in a PR context, we don’t cache coverage data. We just read the report you feed in, and we do it fresh each time.

 
HTH,
Ann

5

Ann,

Thank you for the great info.

I’m not sure what happened with this particular branch (its git history turned out to be messy and full of merges and rebases), but we were able to find a resolution (I was able to get accurate code coverage by creating a new branch and changing the name of the files to something slightly different.)

Thanks again for the thoughtful reply, it helps me understand where the issue might be in the future. (likely with how our coverage report is being generated).

1 Like