False positives with S2187 (test classes supposedly empty)

Clean Code Report False-positive / False-negative...
,
1

We are using Quarkus which allows to run tests in JVM and native mode. The tests are exactly the same but annotations on the test class designated them as either JVM or native test. Hence adding an abstract class with the actual test code makes perfect sense:

@NativeImageTest
class NativeHealthCheckTest extends AbstractHealthCheckTest {
 // empty
}

@QuarkusTest
class JVMHealthCheckTest extends AbstractHealthCheckTest {
 // empty
}

Yet in both cases Sonarqube 7.9 raises S2187 which clearly doesn’t make any sense.

2

Hello @sithmein

Indeed, it seems that we are not supporting Quarkus. I bet you understand that it is not possible for us to support perfectly every possible framework that possibly exists.
Still, the rule has a configurable parameter, to offer you minimal flexibility.
Before going further to explicitly support this framework, can we consider using this parameter? For example, I see that the tests follow a convention, starting with Native or JVM.

What do you think about updating the regex to not consider tests starting with these two names?

3

I’m not asking for a support of Quarkus or any other framework. The rule should simply take the superclasses into account when looking for test methods which it obviously doesn’t.

4

Okay, I see what you mean. I’m surprised though, according to the code and my tests (tested on both SonarQube 8.6 and 7.9), the rule is correctly taking into account the members included in the superclass.

I see two explanations:

  • The rule fails to resolve the parent class.
    This can happen if the project is misconfigured (properties related to Bytecode not set correctly). You might want to double-check them. Providing the logs of the analysis could also help to identify problems. In addition, are you using the SonarScanner or the maven scanner?

  • The rule is not able to detect that the members in the parent class are test.
    Note that no issue will be raised on the parent because abstract classes are not considered by the rule. Is it possible to have more information about the structure of the parent?