[GRADLE-2895] Provide support for "per unit test coverage" reports in sonarqube Created: 24/Sep/13 Updated: 10/Feb/17 Resolved: 10/Feb/17
Sonarqube has a feature that allows it to report on coverage per test case and coverage of lines of code by test cases as described here - https://jira.codehaus.org/browse/SONA...
For TestNG, this is easily done as follows;
For JUnit, this seems to be impossible as there is no way to register an additional `RunListener` that I can see.
The ideal situation would be for the sonar-runner plugin to spot that the jacoco plugin is there and automatically add this feature in (if the sonar plugin is configured to provide per unit test reports).
Is this feature on the radar?
Alternatively, is there a way to register this manually for junit right now that I am missing?
|Comment by Mark Bretl [ 09/Nov/15 ]|
Both SonarQube and Gradle have changed since this issue was opened, however, the issue still exists. Most importantly, since SonarQube 4.3, SonarQube does not run tests, so a listener approach I don't think is not going to work. The way to get 'coverage per test' into SonarQube, is to have JaCoCo sessionId match the test name.
Currently, by looking at the JaCoCo source, it sets the sessionId and other properties at the start of the task, which in this case is 'test'. This limits the sessionId to be set once, instead of for each fork or test. I see this being enhanced by setting the properties at the time of the fork, instead of setting properties at the beginning of the task. The example in the test API/DSL page, https://docs.gradle.org/current/dsl/org.gradle.api.tasks.testing.Test.html, shows how to log the test name before running the test, so it is possible to get the current test. The closure called 'beforeTest' seems to be the best time to set the properties for JaCoCo.
The question is, which I don't know the answer, does 'beforeTest' execute before or after the JVM has been launched? If it is after, then another solution needs be found.
|Comment by Benjamin Muschko [ 15/Nov/16 ]|
As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.
We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.
Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:
We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!
|Comment by Benjamin Muschko [ 10/Feb/17 ]|
Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.