Create new rule in sonarqube

SonarQube Server / Community Build
24

Yeap, this is it. Thank you!

Do you think the test harness could do it automatically? And/or complain of compilation issues?

1 Like
25

Not sure what you exactly mean, but the default behavior for the InternalCheckVerifier (that you get when using CheckVerifier.newInstance(), is meant to work for the sonar-java check tests, and so it points to the local classpath built in the java-checks-test-sources module.

But in your own plugin, you could easily build a wrapper class around this CheckVerifier to provide a verifier instance with your custom classpath already set up. So you could simplify your test classes like:

class SpringControllerRequestMappingEntityRuleTest {

  @Test
  void check() {
    CustomCheckVerifier.newVerifier()
      .onFile("src/test/files/SpringControllerRequestMappingEntityRule.java")
      .withCheck(new SpringControllerRequestMappingEntityRule())
      .verifyIssues();
  }

}

class CustomCheckVerifier {
  public static CheckVerifier newVerifier(){
    return CheckVerifier.newVerifier().withClassPath(FilesUtils.getClassPath("target/test-jars"));
  }
}
1 Like
26

Yes, you are right. I should’ve been more detailed:

According to how you explained to me the missing link for my unit test, it seems that the test (for some reason) needs to have the library (ies) the tests reference.

From that, I am “assuming” that the test is “sort of” compiling the testing source.

Depending on how “correct” is that statement, I’m thinking: If a source is referencing a library that’s missing, then this is a compilation error. Why isn’t the CheckVerifier complaining that the onFile() that it is checking fails to compile?

Of course “there might be cases that this is warranted”. However, I cannot see them now. I’d much rather somewhere between the CheckVerifier.newVerifier()....verifyIssues();, there was some exception raised.

1 Like
27

“sort of” is the correct term here, the code gets parsed, not compiled.
So if there is a syntax error the parser will notice that, but a missing library will only result in a lack of semantic information.
In such cases, rules like the one you are working on will fail to detect signatures because the syntax tree built from the sample file is missing the necessary semantic information to know that JSONAssert.assertEquals is matched by the MethodMatchers you built.

What we usually do when implementing rules that depend on the semantics of third party libraries, is to add also unit tests for cases where the classpath is missing, to assert that the rule will actually NOT raise any issue, without that information

1 Like
28

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.