Allow enabling sonar rules for test sources

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.

5 Likes

Hey,

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?

Cheers,
Michael

1 Like

Hi

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,
Michael

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

Best

-Manuel

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

1 Like

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.

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.

1 Like

Hi,

also ruby and PL/SQL.

Basically for all languages :slight_smile:

Our testers use Selenium/Webdriver to automate unit tests (from inside a C# test project), and they should also have their test scripts evaluated.

Would be awesome to have!

-Dsonar.sources=src -Dsonar.tests=target/test-classes/com -Dsonar.test.exclusions=target/test-classes/com
such parameters allow to check entire code (including tests) as Main sources.

where target/test-classes/com - it’s just an any folder which will not be really verified and it’s just specified to override default sonar.tests parameter.

Is there some status available of it?
Which rules was enabled?

eg rule java:S1128 is still not available for tests classes.

It seems like the “Tests as a First Class Citizen” link is not functional with a newly created Jira account: “This issue may have been deleted or you don’t have permission to view it.”
https://jira.sonarsource.com/browse/MMF-1451

Could you please share an update about this feature?

Please, can you update us on when this feature will be available? As a QA lead trying to insist that my teams treat test code quality in the same way they treat product code quality, it is annoying that SonarQube undermines this by not allowing me to apply the same rules to test code as it does to product code. For enterprise cloud products the test code is vitally important and effectively part of the product now. Ideally, I could use tags or indicate in a quality profile which rules are applied to ;main’ code, which are applied to ‘test’ code and which are applied to all code.

+1 I had exactly the same problem: a bug in test was not discovered by Sonar because it skipped some checks on test sources. It would really help, I am strong believer in keeping test code to the same quality standards as the production code. After all nobody likes flaky tests and random CI/CD failures…

2 Likes

What’s the status of this feature? The docs do not even specify, which rules are applied onto which types of code e.g. production sources or tests, they only state that they differ, see Narrowing the focus with analysis scope
E.g. It seems that “Bugs” and “Security hotspots” are being dropped if while scanning test files, but I couldn’t find any reference in the docs why and how to apply custom settings to this.

This issue is almost 5 years old. Will this be a feature soon or do we have to apply workarounds to our config?

3 Likes