When analyze a test file from “src/test/java” path in a J2EE project, Sonarlint never shows any issue in any test file, but that files in Sonarqube Server that are connected to the Sonarlint instance shows lots of that issues there. The Eclipse installation is new, the Sonarlint installation is OK and that bug appears with the Test files regular expression in Windows → Preferences → Sonarlint option ("**/*Test.java") and withoout any regular expression on it.
The particular thing is that the project where I am trying, has sonar.exclusions and sonar.test.inclusions properties filled in Sonarqube → Analysis Scope settings and sonar.test.inclusions and sonar.exclusions have the same path of test files on them.
Any help would be appreciate
Thanks in advance.
First you use a slightly outdated version of SonarLint for Eclipse and I encourage you to update it (even if it’s not related here).
To better understand what happens here, could you please send us the traces of an analysis of one of those test files ? Make sure to activate verbose traces as described here and redact sensitive parts before posting.
I have analyzed one of those test files in my Eclipse. This test file in Sonarqube server has 65 code smells with the same code, and in Sonarlint has 0 issues.
The main parts in the full trace in Sonarlint Console is:
Trigger: MANUAL
Clear markers on 0 excluded files
SonarLint processing file /esios-qh-api/src/test/java/es/ree/esios/qh/adapters/informationlines/commitment/hvdcfrance/validations/slogans/service/HvdcValidationSlogansServiceTest.java...
File 'src/test/java/es/ree/esios/qh/adapters/informationlines/commitment/hvdcfrance/validations/slogans/service/HvdcValidationSlogansServiceTest.java' qualified as test by 'JavaProjectConfiguratorExtension'
Standalone mode (project not bound)
Starting analysis with configuration:
...
excludedRules: []
includedRules: []
ruleParameters: {}
inputFiles: [
file:/C:/Users/usuario/workspace/ESIOSQH/esiosqh-app/EsiosQH/esios-qh-api/src/test/java/es/ree/esios/qh/adapters/informationlines/commitment/hvdcfrance/validations/slogans/service/HvdcValidationSlogansServiceTest.java (UTF-8) [test]
]
]
TypeScript sensor excluded
Start analysis
Index files
Language of file 'file:/C:/Users/usuario/workspace/ESIOSQH/esiosqh-app/EsiosQH/esios-qh-api/src/test/java/es/ree/esios/qh/adapters/informationlines/commitment/hvdcfrance/validations/slogans/service/HvdcValidationSlogansServiceTest.java' is detected to be 'Java'
1 file indexed
Execute Sensor: JavaSquidSensor
Configured Java source version (sonar.java.source): 8
JavaClasspath initialization
Property 'sonar.java.jdkHome' resolved with:
.....
JavaTestClasspath initialization (done) | time=7ms
Java Main Files AST scan
0 source files to be analyzed
Java Main Files AST scan (done) | time=0ms
Java Test Files AST scan
1 source files to be analyzed
0/0 source files have been analyzed
Unresolved imports/types have been detected during analysis. Enable DEBUG mode to see them.
1/1 source files have been analyzed
Unresolved imports/types:
- BusinessException cannot be resolved to a type
- Consigna cannot be resolved to a type
- Consignas cannot be resolved to a type
- ConversionUtils cannot be resolved
- HashTableToResponseHvdcSlogansConverter cannot be resolved to a type
- Hvdc cannot be resolved to a type
- HvdcSenseLimitSlogansLink cannot be resolved to a type
- HvdcSlogansList cannot be resolved to a type
- HvdcSlogansSense cannot be resolved to a type
- HvdcValidationSlogansService cannot be resolved to a type
- InHvdcValidationSlogans cannot be resolved
- InHvdcValidationSlogansInsert cannot be resolved to a type
- InHvdcValidationSlogansInsertToHashTableConverter cannot be resolved to a type
- InHvdcValidationSlogansToHashTableConverter cannot be resolved to a type
- PopUpMessage cannot be resolved
- PopUpMessage cannot be resolved to a type
- ResponseHvdcSlogans cannot be resolved to a type
- ResponsePopUp cannot be resolved
- ResponsePopUp cannot be resolved to a type
- The import es.ree.esios.operador.beans cannot be resolved
- The import es.ree.esios.operador.servicios.hvdc cannot be resolved
- The import es.ree.esios.qh.adapters.common cannot be resolved
- The import es.ree.esios.qh.adapters.informationlines.commitment.hvdcfrance.validations.slogans.dto cannot be resolved
- The import es.ree.esios.qh.handler cannot be resolved
- Type mismatch: cannot convert from Hvdc to Hvdc
Java Test Files AST scan (done) | time=155ms
Java Generated Files AST scan
0 source files to be analyzed
Java Generated Files AST scan (done) | time=0ms
'PHP sensor' skipped because there is no related file in current project
'Analyzer for "php.ini" files' skipped because there is no related file in current project
'Python Sensor' skipped because there is no related file in current project
Execute Sensor: JavaXmlSensor
0/0 source files have been analyzed
'HTML' skipped because there is no related file in current project
'JavaScript analysis' skipped because there is no related file in current project
Found 0 issue(s)
Done in 206 ms
Is this package coming from the same code base or from a separate library ?
Our java analyzer depends on bytecode to analyze the source code (through the sonar.java.binaries property that should be displayed in the logs at some point). Could you try to build your application with Project > Build Project, or make sure the Project > Build automatically option is enabled ?
The Project → Build automatically option is enabled, I have rebuilt the project and analyze the test file again but the result is the same.
The sonar.java.binaries is pointed to target/classes folder in my local workspace
Could you check if the unresolved imports correspond to folders or class files that exist in the target/classes folder ? Do you have any compiler error in your project or this test file ? I also noticed:
This one plus other errors make me think there is a wrong project configuration. Do the files mentioned in the errors come from the same project or do they come from a library ? Checking the content of the sonar.java.libraries and sonar.java.test.libraries, sonar.java.binaries and sonar.java.test.binaries properties could help. They are displayed in the logs.
Also I see that you use standalone mode (your project is not connected to SonarQube). It could happen that the rules used for analysis are not exactly the same: for example one rule could be disabled by default in standalone mode but activated on the project’s Quality Profile on SonarQube, e.g. leading to issues not raised in SonarLint. What is the rule for which you expect to get issues ? You can have a look here to bind your project to your SonarQube instance.
If this doesn’t help, I would ask you to share with us a minimal reproducer that demonstrates the problem.
Fixing the dependencies problems, when I analyze a test class and then a non-test class the log shows something like this:
Analyzing the test class:
Trigger: MANUAL
File 'src/test/java/es/ree/esios/qh/adapters/cim/breakdowns/controllers/BreakDownsCimControllerTest.java' qualified as test by 'JavaProjectConfiguratorExtension'
File '/esios-qh-api/src/test/java/es/ree/esios/qh/adapters/cim/breakdowns/controllers/BreakDownsCimControllerTest.java' excluded from analysis due to configured server side exclusions
Clear markers on 1 excluded files
Analyzing the non-test class:
Trigger: MANUAL
Clear markers on 0 excluded files
SonarLint processing file /esios-qh-api/src/main/java/es/ree/esios/qh/adapters/cim/breakdowns/service/BreakDownsCimService.java...
Connected mode
Starting analysis with configuration:
[
...
]
Found 1 issue(s)
Download server issues for /esios-qh-api/src/main/java/es/ree/esios/qh/adapters/cim/breakdowns/service/BreakDownsCimService.java
Done in 413 ms
The weird thing is that in Sonarqube server the test class has several issues with the same code.
The only thing I think is related is that in sonar.test.inclusions parameter I have: **/*Test*/** and in sonar.exclusions parameter I have **/*Test*/** too for avoiding problems for set of disjoints and in Sonarlint this exclusions/inclusions parameters are not taking into account
Your project’s folder layout (src/main/java and src/test/java) seems pretty classic. Do you use Maven or Gradle for your project ? Do you use the Scanner for Maven or Gradle in your CI ?
If it’s the case, then you don’t need to specify sonar.test.inclusions or similar properties, the scanner should automatically set them appropriately. SonarLint is also able to automatically detect if a file is a source or test file. Could you try to remove the properties and see if it helps on the SonarLint side ? Make sure to update your binding in the Bindings view.
If you don’t use the Scanner for Maven or Gradle, may I ask why ? If you absolutely need to keep those properties, could you tell me if the project opened in the IDE is the same project analyzed by the scanner ? Is it possible that one is a subfolder of the other ?
The project is analyzed with SonarScanner CLI and it’s not possible to be analyzed with Maven Plugin because it’s a requirement. The properties passed to Scanner (as sonar.exclusions and sonar.test.inclusions retlated) are needed too. The project opened in the IDE is the same project analyzed by the scanner
This **/*Test*/** pattern looks strange to me. It suggests you try to match all subfiles of a folder containing ‘Test’ as part of its name, and it does not match the name of the test file you mentioned. If I use something like **/*Test.java it works on my side.
So SonarLint behaves as expected. Now I don’t understand how issues can appear on this test file on SonarQube… Could it be that this file was analyzed before those inclusions settings changed ? Are you sure it’s still being actively analyzed ?
Finally you were right, the problem was the test pattern ( **/*Test*/**) that was wrong and Sonarqube does not match correctly. I changed the pattern to (**/*Test.java) as you suggested and now my test files are recognized as test files and Sonarlint and Sonarqube server detect them as test files and only shows test file issues, not source file issues as magic numbers, etc