Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »


Sonar Pitest Plugin




Alexandre Victoor




Latest version




Description / Features

PIT is a mutation testing tool for java. You can check out the official pitest web site  for more details on mutation testing and PIT. 

Long story short, mutation testing is a very smart way to check the relevance of unit tests. The main idea is to alter the tested code and check that at least one unit test fails. An alteration of the code is called a "mutant". A mutant has "survived" the tests if there is no test failure. 

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

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

Usage & Installation

Sonar server installation 

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

Since mutation testing is not (yet) officially supported by sonar, 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. 

Project build setup

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

PIT launched by Sonar 

This is the recommended way to go. Most mandatory PIT configuration entries will be set using information provided by the pom.xml file of your project. You just need to activate PIT execution and specify which classes to mutate and tests to execute. Below an example:

Note: you will find at the bottom of this page an exhaustive description of all the configuration parameters.

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 Sonar

You can launch PIT using the PIT maven plugin or the command line runner. PIT execution must be done before sonar analysis. You also need to specify the "reuseReport" mode of the PIT sonar 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 :

inScopeClasses and targetClasses parameters indicated the classes of the system under test where mutations can be performed. In the example above, all the classes from the package and sub packages may be altered. 

Once configured in the maven pom file, you need to run PITusing the following command "mvn org.pitest:pitest-maven:mutationCoverage".

Note : Of course, all the configuration options are clearly explained in the official pitest documentation.

Last but not least, you need to run a sonar 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 sonar will search the latest PIT report in "target/pit-reports". You can specify another location using property "sonar.pitest.reportsDirectory".

You will find below the list of all the available configuration parameters. 

Basic configuration properties

Below the exhaustive list of configuration properties of the sonar 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 sonar 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)

Advanced configuration properties



Default value


Mutate static initializerssonar.pit.mutate.static.initializersfalseWhether or not to create mutations in static initializers. Defaults to false.
Threadssonar.pit.threads1Number of threads to use
Maximum dependency distancesonar.pit.max.dependency.distance-1 (no limit)

Maximum distance to look from test to class. Relevant when mutating static initializers

Calls excluded from mutations

major logging framework APIs

List of packages and classes which are to be considered outside the scope of mutation

Classes not to mutate or run tests from



List of globs to match against class names. Matching classes will be excluded from mutation. Matching test classes will not be run (note if a suite includes an excluded class, then it will “leak” back in).

Methods not to mutatesonar.pit.excluded.methods List of globs to match against method names. Methods matching the globs will be exluded from mutation.
PIT classpathsonar.pit.classpath 

Not useful when maven is used.
Classpath that contains either JUnit or TestNG as well as your code, tests and any dependencies. When maven is used, this classpath is build using maven classpaths.

You can check out the quickstart section of the official pitest web site for detailed instructions.

  • No labels