sonar.testExecutionReportPaths is not working at module level

[vivekweb2013 (Vivek)]

I’ve a multi module maven project with a parent containing 2 child as follows

parent
|
| - frontend
| - backend

The frontend module is a mavenized reactjs project, and backend is a java project.

I’m using jest-sonar-reporter in the frontend module which generates the test-report.xml

The issue - the test-report.xml is only read by sonar scanner if the below property is configured at parent project.

<sonar.testExecutionReportPaths>frontend/coverage/test-report.xml</sonar.testExecutionReportPaths>

If I configure it to the frontend module then the report is not being read by scanner and unit test for frontend projects are not shown on the sonar dashboard.

sonar.testExecutionReportPaths property should be supported at the module level. Defining the module report paths in parent project is simply a violation of modularity principle.

[Colin_SonarSource (Colin)]

Hey there.

I moved this to Get Help as this is known behavior.

As a part of the drop of modules back in SonarQube v7.6 (MMF-365 ), we changed the generic coverage/test reports sensors to be global sensors (SONAR-11530), meaning they only run once for the project (and not for each module).

This means that, for example, users who have sonar.testExecutionReportPaths set in a module’s pom.xml file will no longer have Test Execution data reported.

Feel free to make a suggestion if you think this should be changed (or i can move this thread there). It’s not something we’ve gotten a lot of feedback on.

[vivekweb2013 (Vivek)]

@Colin_SonarSource

Hi Colin, Thanks for the reply. Let me explain my view on this.

First, MMF-365 is very confusing in terms of making a clear distinction about what the word modules means there. Its mentioned - drop the concept of module in SQ/SC So I’m assuming its only related to dropping the module functionality at SQ/SC

Also while looking in detail I’ve found this page Release Upgrade Notes which clearly states that

Concept of module removed from the UI
This version drops the concept of module from the interface
…
For the most part (see below) analysis of multi-module projects will continue to work as it has.

Second, “we changed the generic coverage/test reports sensors to be global sensors” - Why?
I can confirm that below properties are still supported at the module level

sonar.sources
sonar.tests
sonar.javascript.lcov.reportPaths

If these are supported at module level then why not sonar.testExecutionReportPaths ?

Third, Is bit funny but I was checking the SonarJS repository and I have found the below code in this pom file - SonarJS/pom.xml at master · SonarSource/SonarJS · GitHub

  <properties>
    <!--  this is necessary because of drop of modules  -->
    <sonar.testExecutionReportPaths>eslint-bridge/test-report.xml</sonar.testExecutionReportPaths>

See the comment, presence of that comment justifies that it should actually belong to the module level.

Forth, and final, I think reverse mapping child modules properties in the parent project is not a good practice. so I believe this needs to be fixed.

Sorry for this big reply, I would love to hear your thoughts on this. Thanks

[Colin_SonarSource (Colin)]

To be honest, this topic doesn’t really interest me too deeply, I just had the facts I’ll ping somebody who might be able to answer the Why? a little more authoritatively.

[vivekweb2013 (Vivek)]

Thanks
Please move this thread to suggestions if you could.

BTW, found similar post but for gradle, adding link below for reference

sonar.testExecutionReportPaths not triggering the sensor when run from a gradle subproject

I am using SonarQube 7.7 and Gradle 5.4.1 (tested with different versions of Gradle with no change in outcome) I have a simple angular project configured to use karma to generate generic test results along with the standard lcov report. I wrapped the angular project in a Gradle project. If I run the project with the below build.gradle configuration I see the generic test information along with the coverage data (SonarQube overview results shown in pic below) plugins { id 'org.sonarqube' ver…

[marcelstoer (Marcel Stör)]

Allow me to chime in as I just spent a few hours going back and forth with different configuration trying to understand why I am not seeing the frontend tests listed in SQ.

We have the exact same setup as the OP: Maven multi-module with the frontend (Maven) module using the jest-sonar-reporter.

SQ ignoring the sonar.testExecutionReportPaths property defined at module level is IMO a violation of the principle of least astonishment (POLA) - particularly when scanning with Maven. With Maven a property defined at level N+1 (nearly) always replaces a property of the same name at level <=N.

What if you had two frontend modules frontend-A and frontend-B with both having their test-report.xml in different folders? Sure, you can put both paths comma-separated into sonar.testExecutionReportPaths. However, while scanning frontend-A SQ will complain about the missing 2nd path and while scanning frontend-B it will complain about the missing 1st path.

Side note 1: just found out this is a duplicate of GenericTestExecution does not work with maven multi-modules - #19 by neo1203 reported as a bug
Side note 2: if you run the scanner from within frontend rather than project root it works as expected