0

So we use SonarCloud for a .NET Core MVC project in an Azure DevOps pipeline. We noticed we have very low code coverage according to SonarCloud (< 50%) while we have a lot of unit tests. Our organization has no minimum code coverage rules or anything. But the organization thinks that covering lines like String Name { get; set; } is useless.

We notice that a 'Models' project has very low coverage accoriding to SonarCloud, while we think models with nog logic do not need to be tested.

Is there a way to influence the coverage rules? Are there settings for what kind of lines need to be covered and what kind of lines are not usefull to cover?

Any information on the subject is welcome. Thanks in advance.

Martijn
  • 739
  • 9
  • 26

1 Answers1

1

It's pretty easy to set up your own custom quality gate profiles. On your organization's main view that shows all of the projects for your organization, there is a tab just under the organization name called "Quality Gate", select that tab. On the left side are all of the quality gate profiles that are currently in use. There should be one called "Sonar way", with tags "BUILT-IN" and "DEFAULT". In the upper right corner, there is a "Copy" button. Copy the "Sonar way" quality gate, and name it accordingly. With your new quality gate profile created, you can modify the Coverage, Duplicated Lines (%), Maintainability Rating, Reliability Rating, and Security Rating parameters. Once you have the desired settings, you need to assign projects to use that quality gate profile. You can make the newly created quality gate profile the default, which will make all projects use that quality gate profile. You can also target a specific project with your new quality gate profile by selecting the "Without" button under the Projects label, and select the project you wish to use the new profile with. After you do that, you'll then see your project listed under the "With" button. Basically, all projects will use the default quality gate profile unless that profile is specifically assigned to a different quality gate profile.

I find this useful in the early development of a project, when you're creating entity and service model classes (or any POCO style classes), and don't want to waste your time writing tests for the property accessors. Once you have all that code implemented, you can then crank up the coverage requirements for new code.

Steve Scherrer
  • 81
  • 1
  • 7
  • I no longer work for this project, but I passed your comment to my old team. Thanks for answering! – Martijn May 15 '20 at 07:47
  • My team is using sonar cloud in which forces the coverage of 80%, and I believe it is absurd, as it force all non logical method to have test, which by what I see 'till now, it just couple the code to the test tightly and makes it impossible to refactor methods and changes without behavior side effect, without changing the tests... Also when I see so much of this fixture and NSubstitute which fake the internal system, and we specify the input output... we also have lot of methods such as received which sometimes enforce the number calls to a method inside the testing method – Hassan Faghihi Jan 19 '22 at 12:06
  • In continuation of my last message, I should say what I saw in testing of (At least our team) instead of it letting the system evolve while keep the logic and functionality stable, it stop from evolving the system, unless you change the test every few time... :| – Hassan Faghihi Jan 19 '22 at 12:07