Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


The goal of this plugin is to bring PIT results to SonarQubeTM. Right now the integration of these results is quite simple, "survived mutants" on code covered by tests are seen as SonarQubeTM issuesSonarQubeissues.  

Even if PIT detects "survived mutants" on uncovered lines of code, these mutants are simply ignored by the plugin.


  • Mutation testing is very CPU time expensive. It is really important to control the scope of mutation testing in order to keep acceptable SonarQubeTM analysis SonarQubeanalysis times. See below for tips on analysis time.
  • Mutation testing works on true unit tests. Do not try to use it on integration tests, you might mess up your database, file system, whatever external system used by your integration tests. 



Henri Coles, creator of PIT, gave very useful tips on the PIT mailing list to help reduce PIT execution time:

  • Target only specific portions of your codebase (using the class
  • Limit the mutation operators used
  • Limit the number of mutations per class
  • Tweak the number of threads

Check out the "Advanced configuration properties" at the bottom of this page to address the above points.




server installation 

On the SonarQube TM side, just copy the sonar-pitest-plugin jar to the extensions/plugins directory just like any regular SonarQube TM plugin. 

Since mutation testing is not (yet) officially supported by SonarQubeTM, this plugin acts as a "single rule" rule engine... This rule, named "Survived mutant", is disabled by default and hence needs to be activated when pitest is used. 


You have two options in order to produce PIT reports for SonarQubeTM. You can either let the plugin run PIT or you can run PIT prior to the SonarQube TM analysis.

PIT launched by SonarQube


There is a compatibility issue with maven 3.X


The example above tells PIT to mutate classes from packages starting with "". It also specifies that test classes are located in packages starting with "".

PIT launched before SonarQube


You can launch PIT using the PIT maven plugin or the command line runner. PIT execution must be done before SonarQube TM analysis. You also need to specify the "reuseReport" mode of the PIT SonarQube TM plugin. 

Pit needs to be configured in order to generate XML reports. Be aware that PIT default behavior is to generate HTML reports.  Below a simple configuration example for maven :


Last but not least, you need to run a SonarQube TM analysis with the PIT plugin activated in "reuseReport" mode. The following command would do the job :
"mvn sonar:sonar -Dsonar.pitest.mode=reuseReport"

By default SonarQubeTM will SonarQubewill search the latest PIT report in "target/pit-reports". You can specify another location using property "sonar.pitest.reportsDirectory".


Below the exhaustive list of configuration properties of the SonarQube TM pitest plugin.



Default value


Pitest activation mode



Possible values : 'skip', 'active' (not supported yet) and 'reuseReport'

Path to the pitest reports



Path used when mode "reuseReport" is activate to locate pitest xml reports.
Pitest creates a new subfolder "timestamp" at each shot. The SonarQube TM plugin will explore these subfolders and find the newest xml reports generated.

Classes to include in mutation*The classes to be mutated. This is expressed as a comma seperated list of globs. For example com.mycompany.* or com.mycompany.package.*, com.mycompany.packageB.Foo, com.partner.*. When maven is used, the default value is 'groupId*'
Tests to comma seperated list of globs can be supplied to this parameter to limit the tests available to be run. If not specified, the value of "" is used (not recommended)