Allow enabling sonar rules for test sources

(Michael DĂĽsterhus) #1

Please create a configuration option that allows to apply all sonar rules that are evaluated for src/main/java also to be applied to any code in src/test/java

I think it is a common coding guideline that test code has to fulfill the same rules as production code.

Exclude rules from unit tests?
SonarQube Scanner execution fails: java can't be indexed twice
SonarQube Scanner execution fails: java can't be indexed twice
(Michael Gumowski) #2


Thanks for coming to us with this suggestion! You will be probably happy to learn that we are actually already working on the topic, as we also feel that quality and maintainability of tests is important… and it therefore should be nicely covered in SonarQube!

We however realized that it would raise numerous questions in term of integration with existing SonarQube features, because it will have impacts on various metrics and dashboards.

As for today, we are on a really early stage of development, and still mainly brainstorming over the idea, but we are definitely moving forward. You can follow evolution of the expected feature here: Tests as First Class Citizen

Now, we really would like to know from you (or any other user reading this thread and interested by the feature) if you tried to workaround the current limitations of SonarQube. Could you answer the following questions?

  • Did you already try something to also cover your tests with other rules? (for instance: tweaking project configuration, two distinct SQ instances, etc.)
    • If yes, with what results and/or pain points?
  • What language(s) are you targeting?


(Michael DĂĽsterhus) #3


We are targeting java language and our workaround is to use the checkstyle maven plugin with all rules set to severity error which will break the CI build at least on any checkstyle issues. Any other code analysis depends if the user manually starts code inspection in IntelliJ for example. But this is not equivalent to the set of defined sonar rules.

Kind regards,

(Manuel Jordan) #4

It is an interesting topic.

I am very interested in see Sonar applying its features in testing too.

It has a lot of sense for me. I am assuming in some time some plugin should be available to apply the best practices for JUnit 4 and 5.

Not sure what could be the impact or problem about metrics, but about dashboards I would think in two of them to be generated, one for main and other for test. Of course the developer should be strictly controlled for the former in case of error, etc. I mean the current approach. But for the latter perhaps the developer should be free to ignore or not. Of course the developer should not ignore.

Java too. But consider other two branches

  • Groovy for Spock
  • Kotlin



(Michael DĂĽsterhus) #5

No distinction between main and test please. Just put the test violations to the normal issues

(Manuel Jordan) #6

Yes, even with that, we should assume that some plugin for JUnit and TestNG should be created for testing. Same point for Spock and Kotlin.

(KC Baltz) #7

In my case, SonarLint is applying equally to main and test and I would like that to change. My best example is the rule about Magic Numbers, which should almost always be replaced with named constants in production code, but I don’t think that’s true for test code. I think a test case is a lot more readable with literals, so I’d like the ability to have that rule apply in main but not test. However, formatting rules should be universal.

(Karel) #8


also ruby and PL/SQL.