SonarCloud .NET Core coverage is very strict. Is there any way to change this?

Question

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.

Answer 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.