Hello DotNet developers,
We are about to make a change in how we detect “test” projects that are part of your Solution (.sln file). As you may already know, in SonarSource’s products, we make a difference between main projects and test projects. Test projects are only analyzed for issues related to unit tests and nothing more.
We have realized the way we do it today for DotNet Solutions involves a few corner cases. Indeed, we guess that a project of your Solution contains only test files by looking at its name. If the name contains “Test” or “Tests”, then it is automatically considered as a test project and the analyzer will run only the test rules in SonarLint (they are not analyzed at all on SonarQube or SonarCloud for now).
While this was convenient to avoid raising issues that will never be fixed on your test files, this is having a negative impact especially for new users discovering our products. Generally these new users create a simple fake solution made of bad code to evaluate our offering.
Because these users are just testing, they generally name their project “SonarTest”, “TestSonar” and as explained before, SonarCloud/SonarQube will raise nothing on them which would give the feeling that our products don’t detect any issue in the code.
We believe there is a better way to do this and we’re submitting it to you. In the coming weeks, a project will be considered as a “test” project only if it has some dependencies on test artifacts independently of its name.
It will be still possible to explicitly mark a project as being a test or main project by setting the MSBuild property
<PropertyGroup> <SonarQubeTestProject>true</SonarQubeTestProject> </PropertyGroup>
The related documentation will be updated accordingly as soon as the change is effective.
How does that sound to you? If you have any remarks or questions about this upcoming change, please don’t hesitate to ask.