SonarQube supports the reporting of test coverage information as part of the analysis of your C/C++/Objective-C project.
However, SonarQube does not generate the coverage report itself.
-Instead, you must use a third-party tool to produce the coverage report(s) as part of your build process (before the analysis step).
-Later, during the analysis steps, the scanner picks up this report and sends it to SonarQube.
-The coverage is then displayed on your SonarQube project dashboard along with the other analysis metrics.
+Instead, you must set up a third-party tool to produce the report as part of your build process.
+You then need to configure your analysis to tell the SonarScanner where the report is located so that it can pick it up and send it to SonarQube, where it will be displayed on your project dashboard along with the other analysis metrics.
## Adjust your setup
-To enable coverage you need to:
+To enable coverage, you need to:
* Adjust your build process so that the coverage tool generates the report(s).
This is done just after your unit tests as part of the clean build required to run analysis.
## Add coverage to your build process
-For C/C++/Objective-C projects SonarCloud supports a number of coverage tools. Each has an associated analysis parameter that must be set to the location of the coverage report that is produced by the tool. The parameters are:
+For C/C++/Objective-C projects, SonarQube supports a number of coverage tools.
+Each has an associated analysis parameter that must be set to the location of the coverage report that is produced by the tool.
+The parameters are:
* `sonar.cfamily.llvm-cov.reportPath`
* `sonar.cfamily.vscoveragexml.reportsPath`
Assuming that you have already set up your project, you will have seen the example projects (_without coverage_) referenced in the in-product tutorials: [sonarsource-cfamily-examples](https://github.com/orgs/sonarsource-cfamily-examples/).
-To help you add coverage to your project, we also provide, in the same GitHub organization, a few example repositories _with coverage_.
+In the same GitHub organization, you will also find example repositories that provide guidance on how to _add coverage_ to an already-configured project.
+These examples do not explicitly describe every possible combination of tooling and platform but do cover the most significant variants.
+You may need to adapt them slightly:
-Unlike the examples without coverage, not every possible combination of tooling and platform are represented and the examples given are only for SonarCloud. However, adapring them to your needs shuld not be difficult:
+* [Visual Studio Coverage example on GitHub Actions](https://github.com/sonarsource-cfamily-examples/windows-msbuild-vscoverage-gh-actions-sc)
-* [windows-msbuild-vscoverage-gh-actions-sc](https://github.com/sonarsource-cfamily-examples/windows-msbuild-vscoverage-gh-actions-sc)
+* [Visual Studio Coverage example on Azure DevOps](https://github.com/sonarsource-cfamily-examples/windows-msbuild-vscoverage-azure-sc)
-* [windows-msbuild-vscoverage-azure-sc](https://github.com/sonarsource-cfamily-examples/windows-msbuild-vscoverage-azure-sc)
+* [XCode Coverage example](https://github.com/sonarsource-cfamily-examples/macos-xcode-coverage-gh-actions-sc)
-* [macos-xcode-coverage-gh-actions-sc](https://github.com/sonarsource-cfamily-examples/macos-xcode-coverage-gh-actions-sc)
+* [llvm-cov example](https://github.com/sonarsource-cfamily-examples/linux-cmake-llvm-cov-gh-actions-sc)
-* [linux-cmake-llvm-cov-gh-actions-sc](https://github.com/sonarsource-cfamily-examples/linux-cmake-llvm-cov-gh-actions-sc)
+* [gcovr example](https://github.com/sonarsource-cfamily-examples/linux-cmake-gcovr-gh-actions-sc)
-* [linux-cmake-gcovr-gh-actions-sc](https://github.com/sonarsource-cfamily-examples/linux-cmake-gcovr-gh-actions-sc)
+* [gcov example](https://github.com/sonarsource-cfamily-examples/linux-autotools-gcov-travis-sc)
-* [linux-autotools-gcov-travis-sc](https://github.com/sonarsource-cfamily-examples/linux-autotools-gcov-travis-sc)
-
-These examples include the major free-to-use coverage tools for C/C++/Objective-C (VS Coverage, XCode Coverage, LLVM-COV, GCOVR, and GCOV). For information on the populat commercial Bullseye product, see https://www.bullseye.com/.
+These examples include the major free-to-use coverage tools for C/C++/Objective-C (VS Coverage, XCode Coverage, LLVM-COV, GCOVR, and GCOV). For information on the popular commercial Bullseye product, see https://www.bullseye.com/.
## Coverage parameters can be set in multiple places
SonarQube supports the reporting of test coverage information as part of the analysis of your .NET project.
-However, SonarQube does not compile the coverage report itself.
-Instead, you must set up a third-party tool to produce the coverage report as part of your build process.
-During the analysis, the scanner (in this case, the [SonarScanner for .NET](/analysis/scan/sonarscanner-for-msbuild/)) picks up this report and sends it to SonarQube.
-The coverage is then displayed on your SonarQube project dashboard, along with the other analysis metrics.
+However, SonarQube does not generate the coverage report itself.
+Instead, you must set up a third-party tool to produce the report as part of your build process.
+You then need to configure your analysis to tell the SonarScanner where the report is located so that it can pick it up and send it to SonarQube, where it will be displayed on your project dashboard along with the other analysis metrics.
SonarQube supports the following .NET test coverage tools:
We use the `-f xml` parameter to specify that the output format is in XML.
-### **dotCover**
+### dotCover
To use [dotCover](https://www.jetbrains.com/help/dotcover/dotCover__Coverage_Analysis_on_Third-Party_Server.html)
you must install it as a global dotnet tool:
Note that we specify the path to the reports using `sonar.cs.opencover.reportsPaths` because we are using OpenCover.
-### **Coverlet**
+### Coverlet
To use Coverlet, you must install it as a global dotnet tool:
- task: SonarQubeAnalyze@1
```
-## **VB.NET**
+## VB.NET
The examples above are all for C# projects. For VB.NET projects the setup is identical except that you would use these parameters:
SonarQube supports the reporting of test coverage as part of the analysis of your Java project.
-However, SonarQube does not compile the coverage report itself.
-Instead, you must set up a third-party tool to produce the coverage report as part of your build process.
-The SonarScanner will pick up this report and send it to SonarQube where it will be displayed on your project dashboard
-along with the other analysis metrics.
+However, SonarQube does not generate the coverage report itself.
+Instead, you must set up a third-party tool to produce the report as part of your build process.
+You then need to configure your analysis to tell the SonarScanner where the report is located so that it can pick it up and send it to SonarQube, where it will be displayed on your project dashboard along with the other analysis metrics.
For Java projects, SonarQube directly supports the JaCoCo coverage tool
(see [Generic Test Data](/analysis/test-coverage/generic-test/) for information on integrating other coverage tools).
## Adjust your setup
-To enable coverage you need to:
+To enable coverage, you need to:
* Adjust your build process so that JaCoCo report generation step runs _before_ the SonarScanner step.
* Make sure that JacCoCo writes its report file to a defined path in the build environment.
The path can be either absolute or relative to the project root.
-## **Add coverage in a multi-module Maven project**
+## Add coverage in a multi-module Maven project
For multi-module Maven projects, you configure the `jacoco-maven-plugin` in a profile in the parent pom just as in the single module case, above. By default, a separate coverage report will be generated for each module.
SonarQube supports the reporting of test coverage information as part of the analysis of your JS/TS project.
-However, SonarQube does not compile the coverage report itself.
-Instead, you must set up a third-party tool to produce the coverage report as part of your build process (before the analysis step).
-Later, during the analysis steps, the scanner picks up this report and sends it to SonarQube.
-The coverage is then displayed on your SonarQube project dashboard, along with the other analysis metrics.
+However, SonarQube does not generate the coverage report itself.
+Instead, you must set up a third-party tool to produce the report as part of your build process.
+You then need to configure your analysis to tell the SonarScanner where the report is located so that it can pick it up and send it to SonarQube, where it will be displayed on your project dashboard along with the other analysis metrics.
For JS/TS projects, SonarQube directly supports all coverage tools that produce reports in the LCOV format.
Additionally, a generic coverage format is also supported if you wish to use an unsupported tool (though you will have to convert its output to the generic format yourself).
## Adjusting your setup
-To enable coverage you need to:
+To enable coverage, you need to:
* Adjust your build process so that the coverage tool runs before the scanner step.
* Make sure that the coverage tool writes its report file to a defined path in the build environment.
SonarQube supports the reporting of test coverage information as part of the analysis of your PHP project.
-However, SonarQube does not compile the coverage report itself.
-Instead, you must use a third-party tool to produce the coverage report as part of your build process (before the analysis step).
-Later, during the analysis step, the scanner picks up this report and sends it to SonarQube.
-The coverage is then displayed on your SonarQube project dashboard along with the other analysis metrics.
+However, SonarQube does not generate the coverage report itself.
+Instead, you must set up a third-party tool to produce the report as part of your build process.
+You then need to configure your analysis to tell the SonarScanner where the report is located so that it can pick it up and send it to SonarQube, where it will be displayed on your project dashboard along with the other analysis metrics.
For PHP projects, we recommend PHPUnit for testing and coverage reporting.
## Adjust your setup
-To enable coverage you need to:
+To enable coverage, you need to:
* Adjust your build process so that the coverage tool runs _before_ the scanner report generation step runs.
* Make sure that the coverage tool writes its report file to a defined path in the build environment.
run: sed -i 's@'$GITHUB_WORKSPACE'@/github/workspace/@g' coverage.xml
```
-The resulting file should look something like this:
+The resulting file should look something like this:
```
name: build
SonarQube supports the reporting of test coverage information as part of the analysis of your Python project.
-However, SonarQube does not compile the coverage report itself. Instead, you must use a third-party tool to produce the coverage report as part of your build process (before the analysis step). Later, during the analysis step, the scanner picks up this report and sends it to SonarQube. The coverage is then displayed on your SonarQube project dashboard along with the other analysis metrics.
+However, SonarQube does not generate the coverage report itself.
+Instead, you must set up a third-party tool to produce the report as part of your build process.
+You then need to configure your analysis to tell the SonarScanner where the report is located so that it can pick it up and send it to SonarQube, where it will be displayed on your project dashboard along with the other analysis metrics.
## Adjust your setup
-To enable coverage you need to:
+To enable coverage, you need to:
* Adjust your build process so that the coverage tool runs _before_ the scanner report generation step runs.
* Make sure that the coverage tool writes its report file to a defined path in the build environment.
The following shows how to configure the GitHub Actions build file for your Python project so that it works in conjunction with the `tox.ini` configuration file described above to generate code coverage.
Your `build.yml` file should look something like this:
-<!---
-The GitHub Action used in this example is SonarCloud specific.
-Is there an SQ-speciifc variant?
--->
-
```
name: Build
on:
This differs from _test execution reports_, which describe which tests within your test suite have been run during a build. For details, see [Test Execution Parameters](/analysis/test-coverage/test-execution-parameters/).
-Test execution reports are not generated by SonarQube itself.
-Much like tests coverage reports, test execution reports must be generated by an external tool and then imported into SonarQube by specifying a parameter telling the scanner where to look for the report.
+Test coverage reports are not generated by SonarQube itself.
+They must be generated by an external tool and then imported into SonarQube by specifying a parameter telling the scanner where to look for the report.
The data is then displayed in your SonarQube analysis.
Below, you will find language- and tool-specific analysis parameters for importing test coverage reports.
projects / sonarqube.git / commitdiff