SonarQube has become an indispensable tool for development teams striving to maintain high code quality and reliability. One of its most powerful features is the ability to integrate and display unit test results directly within its dashboard. By centralizing code analysis and test outcomes in one place, SonarQube provides a holistic view of software health, enabling teams to identify issues early and enforce quality gates before code reaches production.
Understanding SonarQube Unit Test Integration
SonarQube doesn't execute unit tests itself; instead, it consumes test results generated by external testing frameworks like JUnit, NUnit, MSTest, or pytest. After your CI/CD pipeline runs the tests, it produces a report in a compatible format (typically XML), which SonarQube then imports and visualizes. This integration transforms raw test data into actionable insights, showing not just pass/fail rates but also trends over time and coverage metrics.
Supported Test Frameworks and Report Formats
SonarQube supports a wide range of testing frameworks through its generic test execution report format. The most common integrations include:

- JUnit XML reports for Java projects using Maven or Gradle
- NUnit XML for .NET applications
- pytest with the
--junitxmlflag for Python projects - MSTest TRX files for Visual Studio test runs
- Go test output converted to JUnit format
Configuring SonarQube to Display Test Results
Getting test results into SonarQube requires proper configuration in your sonar-project.properties file or CI pipeline settings. The key property is sonar.testExecutionReportPaths, which points to the generated test report files. For multi-module projects, you can specify multiple paths or use wildcards to capture all relevant reports.
Example Configuration for a Java Maven Project
In a typical Maven setup, the Surefire plugin generates test reports in the target/surefire-reports directory. Your SonarQube scanner configuration would include:
| Property | Value |
|---|---|
| sonar.tests | src/test/java |
| sonar.junit.reportPaths | target/surefire-reports |
| sonar.testExecutionReportPaths | target/surefire-reports/TEST-*.xml |
Interpreting SonarQube Test Metrics
Once integrated, SonarQube presents several critical test-related metrics on the project dashboard. The test success density shows the percentage of passed tests, while test failures and errors highlight problematic areas. The test count provides the total number of tests executed, giving context to the success rate.

Beyond basic pass/fail metrics, SonarQube tracks test execution time, which helps identify performance regressions. A sudden increase in execution time might indicate inefficient test code or resource contention. The skipped tests metric is equally important—excessive skipped tests often signal configuration issues or incomplete test coverage.
Setting Quality Gates Based on Test Results
Quality gates in SonarQube allow teams to enforce minimum standards for test results before code can be merged or deployed. Common quality gate conditions include:
- New code must have at least 80% line coverage
- Test success density must be 100% (no failing tests)
- Overall coverage must not decrease by more than 5%
- No new blocker or critical issues introduced
Troubleshooting Common Integration Issues
Teams occasionally encounter issues when integrating test results with SonarQube. The most frequent problems include incorrect report paths, malformed XML files, or timing issues where the scanner runs before test reports are generated. Always verify that your CI pipeline executes tests before the SonarQube analysis step and that report paths match the actual output locations.
Another common pitfall is version mismatches between testing frameworks and SonarQube's expected formats. Ensure your test framework generates reports in a compatible XML schema, and consider using SonarQube's built-in validation tools to check report integrity before full integration.