Hi,
does anyone if any recent changes made to the coverage rules of sonar cloud? Suddenly we are getting failed PR due to condition coverage. In the submitted files the rule seems to be applied wrongly to getters or setters.
Hello @anastasios,
Are you using C# by any chance? We just released an update to our C#/VB.NET analyzer to better support condition coverage. You can read more about it here.
Hi @TomVanBraband ,
For this reason exactly I made this post. As we saw in the analysis the getters and setters of simple poco objects are considered conditions even though they are just mapping properties from object A to object B for example without participating in any boolean expressions. We tried a lost of additional unit tests to increase condition coverage, checking properties for null, setting values and asserting them but it seems that coverage isn’t changing.
We have fallen back to check only line coverage at the moment which seems to overcome the issue we have.
I had already asked some questions in the topic you are mentioning in your comment. In general, I would say a lot more explanation and different highlights are needed in the analysis view to properly explain why the getters and setters are affecting the condition coverage and how.
hi
Hm, what code coverage tool are you using?
Yes, before implementing we discussed about the possible confusion points, but we decided to move forward and provide coverage information for lines with multiple statements. It’s a current technical limitation that we can only show “conditions” coverage for a line.
Our rationale was that it will be beneficial for our users to see what is not covered by tests in their code, even if currently it’s done in a limited and confusing at first manner.
We are using locally visual studio code coverage and for our pull requests sonal cloud so it’s not that easy to understand the different cases locally. Do you think an extension like sonar lint will help?
The confusion with VS code coverage is also that for a ccov entry (related to one statement) it can show 3 different coverage states: “yes”, “partially” or “no”. We cannot use the “partially” information for condition coverage because it doesn’t say how partial the coverage is (1 out of 5 conditions is not the same with 4 out of 5 conditions). So we consider “yes” and “partially” as being fully covered, and “no” as not being covered.
However, VS code coverage offers multiple entries when there are more statements on a line (1 ccov report entry for each statement). E.g. if a line has 3 statements, 2 covered and 1 not covered, the coverage report will have 3 entries for the line: 2 with “yes” and 1 with “no”. And in that case on 
you’ll see for that line “2 out of 3 conditions are covered”.
It won’t help for coverage. It will help, especially when used in Connected Mode (to have the same Quality Profile as on ), to see issues earlier in the SDLC.
We suggest to use opencover as coverage tool in your CI to have a more accurate depiction of your real code coverage. If you’re using azure pipelines, you can check how we use open cover in our pipeline here.
opencover supports branch/condition coverage - for a statement with 3 branches/conditions, it will say e.g. 1 out of 3 branches/conditions are covered, which we can properly show on .
In other words, for a partially covered statement , VS coverage says “partially” whereas opencover gives the number of total conditions and the number of covered conditions.
@Andrei_Epure we are using vscoverage as our coverage tool. We are using a on-premise dev ops and not azure cloud one and it’s quite difficult to make changes to our tools due to medical software requlations. Nevertheless I will take the suggestion back to our CI/CD team
hello @anastasios
we had a bug when aggregating code coverage data from mutliple test projects
we’re released sonar-csharp 8.6.1 , which reverts the changes we’ve made for VS coverage. It will get deployed to 
in the following days. You should expect the code coverage numbers to increase after that gets deployed (https://sonarcloud.io/api/plugins/installed lists the version of deployed plugins).
Thank you Andrei for the feedback. Looking forward to the udpdate!
Hi Andrei, yes it’s solved now thank you for the support
1 Like
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.