Hi
I’ve seen the announcement
Hello Java devs,
We want to help you write clean test code!
However previously, Sonar was only using a limited set of rules on your test code, see the list here .
Sonar relies on your configuration to determine which files are the main code and which are tests. Our Maven and Gradle scanners handle this, but it can be configured, see the docs .
To improve, we’re reviewing our existing rules for main code to select those that make sense for test code as well.
As a first step, we’ve enabled two …
and various questions whether the analysis scope could be controlled per rule, but without answers, e.g.
Also keep in mind that we have hundreds of thousands of users, and having each of them take the time to review 700+ rules seems like a big ask.
Sure so the default behaviour would be as it is today - tests are only covered by the existing test-only rules, but you have the option to run most/all rules against tests as well as other code, in a configurable way.
You guys reviewing rules and deciding what is/is not noisy from your perspective does not mean that your hundreds of thousands of user…
Is there still no way to control for me as user whether applying a rule make sense for my code base as on test level?
I think it is quite unfortunate if a simple update of Sonar introduces thousands of issues to your codebase.
I would appreciate if it could be controlled on rule level to which scope it should be applied.
Best,
Thomas
Colin
(Colin)
July 8, 2025, 8:27am
3
Hi @Thomas_Mauch ,
Unfortunately, there aren’t any significant updates on this issue. However, I recommend using the Ignore Issues on Multiple Criteria feature at either the global or project level to reduce unnecessary alerts.
For example, to exclude java:S1874
from all test files, you could set up a rule similar to the one shown below:
Hope this helps!