Analyzing test projects without code coverage for them

SonarQube Cloud
, ,
1

We have a SonarCloud subscription for our commercial projects developed using .NET 8 and 9.

We want to analyze both:

  • production code
  • test code

This was easy to achieve using the MSBuild property <SonarQubeTestProject>false</SonarQubeTestProject>.

Unfortunately, now the test projects are reported to have 0% code coverage, which reduces the overall code coverage, which is a problem as it obfuscates production code coverage.

We do not care about test projects coverage. That’s why we excluded it for them using coverlet’s coverlet.runsettings file. It worked and we stopped seeing the excluded test assemblies in the generated XML file.

Unfortunately SonarCloud still reports 0% code coverage for the test projects and overall code coverage is wrongly reduced. How can we configure SonarCloud not to expect code coverage for certain projects?

2

Hi,

Welcome to the community!

We don’t read/honor the coverage engine’s exclusions. You’ll need to set SonarCloud coverage exclusions, ideally via the project settings UI.

 
HTH,
Ann

3

Hello Ann,

Thanks for your response. I read the documentation in the link provided.
I applied the changes using the CICD script we already have by adding the parameter: /d:sonar.coverage.exclusions="**/*.Tests*,**/*.Testing*"

Unfortunately I am still seeing the code coverage for these projects to be 0% rather than the long dash — indicating it isn’t included.

Screenshot from 2025-02-26 18-38-53
Screenshot from 2025-02-26 18-38-531185×379 27.5 KB

These are the logs from this pipeline run:

INFO: Sensor C# Tests Coverage Report Import [csharpenterprise]
INFO: Parsing the OpenCover report /home/vsts/work/1/./code-coverage/ba306b11-d7de-4453-8144-a48ee388a733/coverage.opencover.xml
INFO: Adding this code coverage report to the cache for later reuse: /home/vsts/work/1/./code-coverage/ba306b11-d7de-4453-8144-a48ee388a733/coverage.opencover.xml
INFO: Parsing the OpenCover report /home/vsts/work/1/./code-coverage/c56489a6-c679-4e6c-97f5-63f4ddb603c8/coverage.opencover.xml
INFO: Adding this code coverage report to the cache for later reuse: /home/vsts/work/1/./code-coverage/c56489a6-c679-4e6c-97f5-63f4ddb603c8/coverage.opencover.xml
INFO: Coverage Report Statistics: 32 files, 32 main files, 32 main files with coverage, 0 test files, 0 project excluded files, 0 other language files.
INFO: Sensor C# Tests Coverage Report Import [csharpenterprise] (done) | time=295ms
INFO: Sensor Zero Coverage Sensor
INFO: Sensor Zero Coverage Sensor (done) | time=5ms

Any idea what I did wrong?

4

Hi,

These are glob patterns, not regular expressions. * means ‘all files’, not ‘0-n characters’. Try this:

/d:sonar.coverage.exclusions="**/*.Tests/**/*,**/*.Testing/**/*"

 
HTH,
Ann

Edit: In a file path spec, * has the effective meaning of ‘all files’ but it does actually mean ‘0-n’ characters. Doh!

1 Like
5

Thanks, Ann. I was just re-reading the docs after my previous comment and I saw:
* matches zero or more characters (not including the directory delimiter, /).
After which I changed my patterns and things worked.

I came to share my fix but you already had responded. Thank you very much for the support. I think the issue is resolved now.

1 Like
6

Hi,

Could you point me to what you were reading? Because in the context of exclusions, * is not “0 or more characters”.

 
Thx,
Ann

7

Sure. I followed the link you gave me for exclusions which had a link to defining matching patterns - just expand the On the CI/CD host section to see it. It made sense for me, but if you think it can be further improved, I guess it would benefit the community even more.

1 Like
8

This morning, that page on “defining matching patterns” was missing its URL slug, so I fixed it.
I edited the post to correct the URL; I hope that’s okay with you, @cvetomir-todorov, I only changed the URL.

2 Likes
9

Thank you, keep up the good work, guys.

1 Like