TL;DR overview
- SonarQube supports importing unit test reports generated by external test frameworks, enabling teams to incorporate test results from any tool that produces JUnit-compatible XML output into their SonarQube quality metrics.
- The generic test execution import format allows teams using non-standard testing frameworks, multi-language projects, or custom test runners to feed results into SonarQube without changing their testing infrastructure.
- By centralizing test results alongside static analysis findings, teams get a unified view of code health—correlating coverage gaps with code quality issues to prioritize both remediation and test investment.
- Teams migrating to SonarQube from other analysis platforms should review the generic test execution import documentation to confirm compatibility with their existing test output format.
For many, it is getting very tempting to switch to Sonar to centralize the quality management of source code and take advantage of the numerous functionality such as TimeMachine, Classes clouds, Consolidated dashboards, Drill downs... In Sonar 1.7, we have added a very useful feature that we did not discuss too much so far : the possibility to re-use reports generated by external quality systems in order to smoothly evaluate Sonar without having to break the legacy quality platform. Today, were going to discuss two use cases where this feature can be leveraged.
1. Switching from Maven Site to Sonar
This is a very common situation : you are already managing the quality of your source code through the Maven Site by generating sites on 250 projects, for instance, with every quality reports activated. Your team uses the maven site extensively and switching to Sonar in a big bang approach is simply not possible.
You have read the post "Maven Site, Sonar or both of them ?" on the Sonar blog but you don't feel right to suddenly ask everybody to switch to Sonar. You realize that you need to run them both in parallel for some time. But given the fact that it takes already a long time to generate the sites, it is not possible to double this time by doing the analysis in Sonar as well.
That is where the "ReuseReport" functionality of Sonar 1.7 comes into play, it is now possible to have a staged approach ! The principle is fairly simple, it consists of indicating to Sonar that it should use reports that have already been generated by the Maven site, the ones that are the most hungry in CPU and memory : unit tests execution and/or code coverage calculation. This can be achieved by simply adding "-Dsonar.dynamic=reuseReports" to the Sonar maven command line.
It is then possible to keep both systems running in parallel for some time at a slightly higher cost until you decide to make a complete switch to Sonar. When you have switched off the quality reporting in the Maven site, you can even reference Sonar in the Maven site by using the Sonar Maven report plugin.
2. Using Sonar in its full capability in an ANT environment
If you are using ANT to build your applications, the main weakness so far in Sonar was that it did not allow to display Unit tests results nor Code coverage. I am sure that now you have read the first use case, you know that by using the "-Dsonar.dynamic= reuseReports" parameter, this limitation does not exist anymore. You simply need to specify where those reports to reuse are going to be found, by using the following properties : sonar.cobertura.reportPath, sonar.clover.reportPath, sonar.surefire.reportsPath...
With this new functionality, Sonar gives a similar level of quality information on ANT projects that there is on Maven projects.