Dotnet setter code coverage in serialization scenarios

also, for projects that contain only POCOs and serializable objects (that must have a setter), I don’t really care about Condition Coverage, as I don’t want to have to test setters that will ultimately only be called by a serialization framework.

hi @larryautravail

I moved your message on a separate topic to be able to discuss here

regarding

can you please share with us more details? how much did your code coverage drop? is it just because POCO serializable objects with uncovered setters or is there something else?

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 :sonarcloud: in the following days. You should expect branch (conditional) code coverage to increase.

To be clear:

  • we fixed the import of branch coverage from OpenCover reports (OpenCover and coverlet have good support for branch coverage)
  • we’ve reverted the changes we did for VS coverage and dotCover, which don’t have support for branch coverage

What we did in 8.6 (and reverted in 8.6.1) for all tools (VS Coverage, dotCover and OpenCover): in addition to branch coverage, we were also looking when there were multiple statements per line, some covered and some not covered. And were showing the incomplete coverage using the “conditional coverage” feature from sonarcloud. We’ve reverted this feature because we need to rethink it in order to support multiple-statements-per-line coverage results from multiple test projects.

To sum up:

  • you won’t see “conditional coverage” for the getter/setter scenario.
  • OpenCover branch coverage will now be imported correctly when coming from multiple test projects