Addressing SonarQube Code Coverage Analysis: Prioritizing Unit Test Reports Over Auto-Detected Files

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube Server / Community Build, Scanner, Plugin, and any relevant extension) - SonarQube Server Enterprise 2025.3
  • how is SonarQube deployed: zip, Docker, Helm - Helm
  • what are you trying to achieve - Code coverage based on only provided coverage reports
  • what have you tried so far to achieve this -
    Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!

We have recently upgraded to SonarQube Server Enterprise 2025.3 and have identified an issue related to code coverage results as compared to the previous version 9.9 LTA.

We are trying to scan a NodeJS / Typescript project and its unit tests are generating the coverage reports ( lcov.info ). This report was imported by SonarQube and the coverage results were displayed as per this report in the previous version 9.9 LTA.

In the current version 2025.3, the behavior has changed, it has added its own detected files along with the coverage info and displaying coverage results much lower than the previous version.

We are expecting it to purely listen to the lcov.info when evaluating the coverage.

Could you please help how to fix this issue?
Please inform me if you require additional information such as logs, I can provide the necessary details.

Hey there

I’m not sure what you mean by this. Can you give some more details?

Hi @Colin
Thanks for your comment.
We’ve recently updated to SonarQube Server Enterprise 2025.3 and noticed a discrepancy in code coverage results compared to the previous version, 9.9 LTA.

Currently, we’re scanning a NodeJS/TypeScript project, with unit tests generating coverage reports (lcov.info). In version 9.9 LTA, SonarQube imported and displayed coverage results based on this report.

However, in version 2025.3, the behavior has changed. It now includes its own detected files (information about files that are not present in the lcov.info), resulting in lower coverage results than before.

We expect SonarQube to solely rely on the lcov.info file for coverage evaluation.

Can you assist on this?

This behavior—counting uncovered files that are present in the codebase but not in the lcov.info report—has remained the same for a long time (probably 10 years?)

The drop in reported coverage is likely due to the JavaScript/TypeScript analyzer being improved to recognize or index more files in your project than before.

As a result, files previously ignored or undetected are now included in the analysis, and if they lack coverage info in lcov.info, they are treated as untested, reducing overall coverage.

You can always review your project’s analysis scope and consider excluding these files from coverage calculations, as outlined in the SonarQube documentation.