I’m not seeing that in the rule description. In fact, analysis recognizes tests because they’re identified as such either manually via sonar.tests or automatically by the SonarScanner for Maven or SonarScanner for Gradle.
How are your sonar.sources and sonar.tests identified for analysis?
I need to wait for my colleague, who manages our Sonar server. But, what I can tell, is, that the last paragraph from the rule’s description days this:
Note: this does not apply for assert from Java itself or if the source code package name is related to tests (contains: test or assert or junit).
I’m not sure, if test classes are identified as such other than that here.
I had the chance to ask our Sonar server guy. And the decision, whether to handle a test class as test is indeed done by scanner settings.
In Lint it is done as the description says.
So my question now is: Can this be changed, so that Lint recognizes tests as tests, if annotated with one of the @Test annotations. I’m not sure, if a “Test” in the class name wuold be a good idea for detection. This could also refer to some other test meaning.
Hello, thank you for the report.
I agree that the rule could be slightly more sophisticated, and allow assertions inside annotated test methods.
I created a ticket for this.
The implementation in SonarQube for IDE (SonarLint) relies on the Information provided by Eclipse JDT whether or not a Source Directory (and therefore the Packages and classes) are marked as Test Code or not.
Would you be so Kind to provide the .classpath file? The IDE Plug-in May raise the issues incorrectly whenever the entry for the Test Code Directory does Not Contain the Test Attribute.
This might therefore be here Both an issue with the Rule and the IDE Plug-in Not getting the correct values for the actual analysis. This behaviour differs from the analysis against SonarQube Server or Cloud, as the IDE Plug-in creates sonar.tests etc. Automatically based on the IDE and project configuration.
