Adding SonarQube coding rules using Java for the Test Automation Suite

As QE’s or Developers we have to deal with hundreds or even thousands of code lines every day in our life. As humans dealing with such amount of code lines, there may be code smells, bugs, security vulnerabilities in our scripts. SonarQube is an open-source platform developed by SonarSource for continuous inspection of code quality to perform automatic reviews with static analysis of code to detect such things in our scripts.

There are predefined set of rules in SonarQube and you can add them as an extension to your IDE or as a server to your pipeline. Apart from these predefined rules, anyone can write their own set of project-related rules and add that as a plugin to your project.

Adding Custom Coding Rules

There are two ways to extend coding rules:

• Writing coding rules using Java via a SonarQube plugin
• Adding XPath rules directly through the SonarQube web interface

But the preferred way is to write the rules via a SonarQube plugin. Here I’m only going to talk about writing the rules via a SonarQube plugin method using Java.

Adding coding rules using Java

Writing coding rules in Java is a six-step process:

• Create a SonarQube plugin.
• Put a dependency on the API of the language plugin for which you are writing coding rules.
• Create as many custom rules as required.
• Generate the SonarQube plugin (jar file).
• Place this jar file in the SONARQUBE_HOME/extensions/plugins directory.
• Restart the SonarQube server.

Writing coding rules using Java

Here I’m going to talk about how we can write the custom rules. For that, I’m using the Java example given by the https://github.com/SonarSource/sonar-custom-rules-examples.

In the sample project, the Checks package in the main is used to write the custom rules. In parallel to that, we can see four classes that help to execute the rules.

RulesList

As I mentioned above the custom rules that we created on the Checks package are added to a list and return that list in this class. So every time when you adding a new rule class to the Check package you have to add that class name to the list in this class.

MyJavaRulesPlugin

This class defines the server extensions and the batch extensions. In server extensions(MyJavaRulesDefinition), objects are instantiated during server startup, and in the batch extensions(MyJavaFileCheckRegistrar), objects are instantiated during code analysis.

MyJavaRulesDefinition

This is the server extension class that I explained above. In this class, we can define the attributes like REPOSITORY_KEY, REPOSITORY_NAME, RESOURCE_BASE_PATH &, etc. Also, this will check whether the Rule annotation is there in custom rule classes as it’s a must.

Writing a custom rule to verify whether the test method name is starting with the “test” or “verify” prefix.

As an example, let's take we want a rule to verify that our test method names to start with “test” or “verify” prefix. So we can write a rule like below.

Sample Custom Rule

Here you can see the Rule annotation is added before the class declaration as it is mandatory. I have overridden the visitMethod in the MethodTree class. If you need to check something in the class you can use the ClassTree, if you need to check something in the imports you can use the ImportTree. Likewise, there are so many classes that we can use to write the custom rules.

In the above example first I have added all the annotations in the test method to a list and check whether there is an annotation called “Test” to identify whether that method is a test method or not. If it's a test method I have checked that the “test” or “verify” prefix is available in the method name. If not I have thrown an error message.

After writing the rule we have to add the metadata files to the resource folder of the main package which consists of an HTML file and a JSON file. The file name should start with the key value that is given to Rule annotation in Rule class.

TestMethodNames_java.html

In the HTML file, you have to mention the error message which is similar to the given in the Rule class, the noncompliant solution, and the compliant solution. When there is a sonar violation you can see these values in the sonar report.

TestMethodNames_java.json

In the JSON file, you have to mention the issue title, type of the issue, issue status, time taken to fix the issue, and the severity of the issue. These values also can be found in the sonar report of a sonar violation.

Now the rule writing part is done. Now we have to test whether our rule is working fine or not. For that we can write a sample test as follows.

TestClass

In this test I have verify the content in the TestMethodsNamesCheck.java file against our rule. So lets see what’s in the TestMethodsNamesCheck.java file.

TestMethodsNamesCheck.java

In TestMethodsNamesCheck.java file which is in the Test resources folder, I have included some sample Non-compliant and Compliant solutions. You can include any number of Noncompliant and Compliant solutions here. For the NonCompliant ones you have to mention it as a NonCompliant and the error message, which you gave in the Rule class. If the two messages are different the test will fail. Also there should be at least one Compliant and one Noncompliant solution in your test. For the Compliant ones you have to mention it as a Compliant and no message needed. Now you can execute the test and see whether your rule working fine.

The sample project can be found in here and more info here.

Hope you learn something useful. See you in the next one ✌️