Problem with rule 'Test classes should comply with a naming convention'

SonarQube v7.9.4 LTS
SonarJava 5.13.1 (build 18282)

It seems there is some problem with the Java rule - ‘Test classes should comply with a naming convention’ (squid:S3577). It does not report any violations with default regex pattern or even with changed pattern.

I have created a test class with name

import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

public class Foo {

   	public void setup() {
		System.out.println("Before Each setup() method called");
	public void testOne() {
		System.out.println("Test one"); 
	public void testTwo() {
		System.out.println("Test two"); 
	public void clean() {
		System.out.println("After Each clean() method called");

I am expecting the rule to report a bug because class contains a test and class name does not comply with the pattern (as also shown in the rule documentation) but no findings reported.

What’s wrong ?


Is this file identified to SonarQube as a test file? I.e. does its location match the pattern supplied for sonar.tests?


Yes, SonarQube is reporting the number of tests executed in this file, so I believe it is able to identify it as a test file.

And yes, sonar.tests have been defined as:

and is lying under this folder only.


Thanks for verifying. Let’s wait for the language specialists to pick this up.


Just realized that even the rule “Test methods should comply with a naming convention” is not reporting any violations.

Made a change from “test” to “tet” but rule does not report anything.


Hello @ankurja,

In SonarQube v7.9.4 LTS, both rules you are mentioning are not included in the default quality profile, therefore not executed by default. You have to activate them in a quality profile and make sure this profile is used by your project. I just tried to analyze your code on my side with this setup, and the issues were detected.

By the way, these rules, and many more targeting tests code, are enabled by default in recent versions of SonarQube, you should try them out!


Hi @Quentin,

I have been a SonarQube user since many years now, you can trust me to have this much understanding of the tool. :slight_smile:

Profile that I am using is called “MyJavaProfile”.


and all 15 unit tests related rules available in Java ruleset are active there:

Glad to see that you already made sure the quality profile was correctly setup.

It seems to me that you are using Sonarscanner and not the recommended Scanner for maven. Is it correct? Out of curiosity, could you briefly explain why?

My test was with the scanner for maven, and it worked just fine. It’s probably due to the fact that it set up all required properties. I will have a try with the sonarscanner and eventually come back to you.

Hi @Quentin, The project is configured to use ant, not maven (sonarqube-ant-task- and I have set following properties in build.xml. Tests are being executed successfully and SonarQube is able to detect the test results, but not reporting any code violations.

<property name="sonar.projectKey" value="test" />
<property name="sonar.language" value="java" />
<property name="sonar.sources" value="src/main/java" />
<property name="" value="build/main" />
<property name="sonar.tests" value="test" />

Okay, that makes sense.

My next guess would be that you are missing/misconfiguring, is that possible?
In case it is missing, you should see a message in the logs of the analysis:

WARN: Bytecode of dependencies was not provided for analysis of test files, you might end up with less precise results. Bytecode can be provided using property.

When it is misconfigured, the message will not appear but the result will still be less precise (we are working to improve the logs as we speak). You have to make sure that all test dependencies are correctly provided.

For example, in my sample project reproducing your case, I added in the configuration, and made sure this folder contains junit-jupiter-api-5.7.0.jar.

By the way, you can also check that is correctly configured aswell, since it is the equivalent for main files.

Thanks @Quentin, this was the trick. I had noticed those warnings on the console but it said results will be “less precise”, which is different from “no findings at all”. Looks like this property is a must for any of the 15 unit testing related rules to work (at least when Ant is being used). Might help others if documentation and the warning message gets updated.

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