I have developed custom SonarQube rules and categorized them separately for src/main and src/test. In my plugin, I register the rules using the following code:
However, rules that I have defined specifically for source code are still being raised as issues on test code.
I also tried explicitly setting sonar.sources and sonar.tests separately, but in our large multi-module project, this is problematic because not all modules have a src/test directory. When a module lacks src/test, the analysis fails with the following error:
Error message
The directory 'myModule/src/test' does not exist for Maven module myModule:jar:0.0.1-SNAPSHOT. Please check the property sonar.tests.
Additionally, I could not find an option in the SonarQube UI to distinguish between rules meant for source and test code.
My questions:
How can I ensure that specific rules apply only to src/main and others only to src/test both when it comes to custom rules and SonarWay rules?
What is the recommended way to configure SonarQube in a large multi-module Maven project to properly apply different rules for production and test code without causing failures for modules that lack src/test?
You don’t say that you’ve specified sonar.tests. An inclusion is a narrowing of the initial scope. But without a sonar.tests parameter, there is no initial scope.
If you’re building and analyzing with Maven, it’s not clear to me why you would be setting either sonar.sources or sonar.tests manually. The benefit of analyzing with Maven is that it reads most of your analysis configuration from the build environment. What happens if you don’t do any of this manual specification?
That’s done in the writing of the rule, not in the UI.
My best suggestion is code-diving in the Java analyzer repo to see how the native, test-related rules are made to target test files.
src.test uses maven default configuration. so we don’t specify that.
The main reason is because we see a value of many of the rules ment for src/main also for unit tests.
Our product is a Test Framework testing radio equipment, under src/test we add our unit tests, in our Test Project we add production tests under src/main which also uses TestNg and Asserts to test our products.
Some rules make sense to enable both for src/main and src/test.
If I try to figure out which rules are ment for what, the only part that can give me a hint is the tag, e.g. the tag “test”, but it is not clear that this rules for Assertions only will be valid for src/test, in our case I would need them for both.
As I understand it is not done in the rule it self, it is done in the registration of the rules.
So I missing a way to list all the rules that are ment for src/test and src/main
I also missing the possibility to enable specific rules for test only without re registration of all the rules. I think at least it should be visible somewhere which rules are ment for what in the UI without dig in to the code to understand that.
To be honest, running “normal” rules on tests has been a recurring discussion over the years, and one that hasn’t moved nearly as much as I’d hoped. The last time this came up, we turned on several rules for tests and then… saw a squirrel.
I’m going to flag this for the PMs. (But don’t hold your breath.)