There is definitely an issue with
dotnet test --collect "Code coverage"
usage (which utilizes MS Tests underneath). We currently have
for all new getter/setter properties which are actually covered by tests.
We have to exclude POCO models from coverage as a workaround to fulfil the quality gate requirements. Please, fix!
1 Like
hi @mkarpuk
can you please provide us with more details about the code being covered? can you share with us the coverage reports for the code snippet ?
maybe it’s a configuration problem of how you run the tests - if there are only 1 getter and 1 setter, it should not consider 20 conditions.
can you run the BEGIN step in verbose mode and then give us the logs of the END step?
e.g.
SonarScanner.MSBuild.exe begin /k:"MyProject" /d:sonar.verbose=true
Hello,
I’m sorry for not being responsive – we have tough time preparing for the product release.
I can’t share coverage report as is since the source code is private.
I will try to prepare a code snippet as soon as I have free time.
I guess the issue could be in using multiple test dlls and the way how results are merged by the dotnet tool.
we’ve seen this problem with xunit and needed to use the -noshadow option to avoid creating shadow copies of assemblies - as the shadow copies were getting analyzed and lead to duplicate coverage information
maybe you can investigate that on your side
I think I have a similar issue. I have a solution with a single source assembly, and two xUnit testing assemblies. I have a simple POCO style class with some get/set properties. The Sonar coverage details show “Partially covered by tests (2 of 4 conditions)” while also showing zero uncovered lines. The POCO class is directly referenced by a test class in the UnitTest project, but not in the IntegrationTests project. The solution directory looks like this:
Domain/
–src/
----Domain/ <-- All source files under test are found in this directory
–tests/
----UnitTests/
----IntegrationTests/
Based off the replies I’ve read so far in this thread, I found this article about setting xUnit configuration (https://xunit.net/docs/configuration-files). Based on that article, I created [UnitTests | IntegrationTests].xunit.runner.json files in each xUnit test project at the project root directory. The JSON looks like this:
{
“$schema”: “https://xunit.net/schema/current/xunit.runner.schema.json”,
“shadowCopy”: false
}
The solution is getting built in Azure DevOps, so we’re using SonarCloud build tasks. Here is the YML of the Test task for the relevant pipleline:
- task: DotNetCoreCLI@2
displayName: Test
inputs:
command: test
projects: (TestProjects) arguments: '--collect "Code coverage" --configuration (BuildConfiguration)’
I still seem to have the same problem. I just set sonar.verbose=true for the last build and I’m looking at the log right now, but not finding anything so far. I would prefer to keep the automated tests separated as UnitTests and IntegrationTests, and not migrate all tests into a single test project
I would greatly appreciate any other ideas or insight on this issue. TIA for any help provided.
As a small experiment, I implemented the same test class in the IntegrationTests project that exists in the UnitTests project, but only tested one of the properties of the POCO class. Sure enough Sonar shows that all 4 conditions for that property are now covered. The issue is definitely associated with having multiple test projects.
Indeed, I opened Fix Code coverage import from multiple test projects · Issue #3296 · SonarSource/sonar-dotnet · GitHub to track this problem. It will get fixed in the next version.
We’re released sonar-dotnet 8.6.1 , fixing the branch coverage import bug when importing data from multiple test projects. It will get deployed to 
in the following days. You should expect branch (conditional) code coverage to increase.