gradle-pitest-plugin.solidsoft.infoGradle plugin for PIT Mutation Testing | gradle-pitest-plugin

View On GitHub ZIP TAR DOWNLOADS gradle-pitest-plugin Gradle plugin for PIT Mutation Testing Project maintained by szpak Hosted on GitHub Pages — Theme by mattgraham Gradle plugin for PIT Mutation Testing The plugin provides an ability to perform a mutation testing and calculate a mutation coverage of a Gradle -based projects with PIT . Quick start The simplest way Add gradle-pitest-plugin to the plugins configuration in your build.gradle file: plugins { id ’java’ //or ’java-library’ - depending on your needs id ’info.solidsoft.pitest’ version ’1.15.0’ } Call Gradle with pitest task: gradle pitest After the measurements a report created by PIT will be placed in ${PROJECT_DIR}/build/reports/pitest directory. Optionally make it depend on build: build . dependsOn ’pitest’ Note that when making pitest depend on another task, it must be referred to by name. Otherwise Gradle will resolve pitest to the configuration and not the task. Generic approach The plugins way” has some limitations. As the primary repository for the plugin is the Central Repository (aka Maven Central) it is also possible to add the plugin to your project using the generic way”: buildscript { repositories { mavenCentral () //Needed only for SNAPSHOT versions //maven { url ’https://oss.sonatype.org/content/repositories/snapshots/’ } } dependencies { classpath ’info.solidsoft.gradle.pitest:gradle-pitest-plugin:1.15.0’ } } Apply the plugin: apply plugin: ’java’ //or ’java-library’ - depending on your needs apply plugin: ’info.solidsoft.pitest’ Plugin configuration The Pitest plugin does not need to be additionally configured if you use JUnit 4. Customization is done in the pitest block: pitest { targetClasses = [ ’our.base.package.*’ ] //by default "${project.group}.*" pitestVersion = ’1.15.0’ //not needed when a default PIT version should be used threads = 4 outputFormats = [ ’XML’ , ’HTML’ ] timestampedReports = false } The configuration in Gradle is the real Groovy code which makes all assignments very intuitive. All values expected by PIT should be passed as a corresponding types. There is only one important difference. For the parameters where PIT expects a coma separated list of strings in a Gradle configuration a list of strings should be used (see outputFormats in the example above). Check PIT documentation for a list of all available command line parameters. The expected parameter format in a plugin configuration can be taken from PitestPluginExtension . To make life easier taskClasspath , mutableCodePaths , sourceDirs , reportDir , verbosity and pitestVersion are automatically set by the plugin. In addition sourceDirs , reportDir , verbosity and pitestVersion can be overridden by a user. There are a few parameters specific for Gradle plugin: testSourceSets - defines test source sets which should be used by PIT (by default sourceSets.test, but allows to add integration tests located in a different source set) mainSourceSets - defines main source sets which should be used by PIT (by default sourceSets.main) mainProcessJvmArgs - JVM arguments to be used when launching the main PIT process; make a note that PIT itself launches another Java processes for mutation testing execution and usually jvmArgs should be used to for example increase maximum memory size (see #7 ); additionalMutableCodePaths - additional classes to mutate (useful for integration tests with production code in a different module - see #25 ) useClasspathFile - enables passing additional classpath as a file content (useful for Windows users with lots of classpath elements, disabled by default) fileExtensionsToFilter - provides ability to filter additional file extensions from PIT classpath (see #53 ) For example: pitest { ... testSourceSets = [ sourceSets . test , sourceSets . integrationTest ] mainSourceSets = [ sourceSets . main , sourceSets . additionalMain ] jvmArgs = [ ’-Xmx1024m’ ] useClasspathFile = true //useful with bigger projects on Windows fileExtensionsToFilter . addAll ( ’xml’ , ’orbit’ ) } Test system properties PIT executes tests in a JVM independent of the JVM used by Gradle to execute tests. If your tests require some system properties, you have to pass them to PIT as the plugin won’t do it for you: test { systemProperty ’spring.test.constructor.autowire.mode’ , ’all’ } pitest { jvmArgs = [ ’-Dspring.test.constructor.autowire.mode=all’ ] } Eliminate warning in Idea As reported in #170 IntelliJ IDEA displays warnings about setting final fields (of lazy configuration ) in build.gradle . It is not a real problem as Gradle internally intercepts those calls and use a setter instead . Nevertheless, people which prefer to have no (less) warnings at the cost of less readable code can use setters instead, e.g: testSourceSets . set ([ sourceSets . test , sourceSets . integrationTest ]) mainSourceSets . set ([ sourceSets . main , sourceSets . additionalMain ]) jvmArgs . set ([ ’-Xmx1024m’ ]) useClasspathFile . set ( true ) //useful with bigger projects on Windows fileExtensionsToFilter . addAll ( ’xml’ , ’orbit’ ) Similar syntax can be used also for Kotlin configuration ( build.gradle.kts ). Multi-module projects support gradle-pitest-plugin can be used in multi-module projects . The gradle-pitest-plugin dependency should be added to the buildscript configuration in the root project while the plugin has to be applied in all subprojects which should be processed with PIT. A sample snippet from build.gradle located for the root project: //in root project configuration plugins { id ’info.solidsoft.pitest’ version ’1.15.0’ apply false } subprojects { apply plugin: ’java’ apply plugin: ’info.solidsoft.pitest’ pitest { threads = 4 if ( project . name in [ ’module-without-any-test’ ]) { failWhenNoMutations = false } } } It is possible to aggregate pitest report for multi-module project using plugin info.solidsoft.pitest.aggregator and task pitestReportAggregate . Root project must be properly configured to use pitestReportAggregate : //in root project configuration plugins { id ’info.solidsoft.pitest’ version ’1.15.0’ apply false } apply plugin: ’info.solidsoft.pitest.aggregator’ // to ’pitestReportAggregate’ appear subprojects { apply plugin: ’java’ apply plugin: ’info.solidsoft.pitest’ pitest { // export mutations.xml and line coverage for aggregation outputFormats = [ "XML" ] exportLineCoverage = true timestampedReports = false ... reportAggregator { //since 1.9.11 - extra results validation, if needed testStrengthThreshold . set ( 50 ) //simpler Groovy syntax (testStrengthThreshold = 50) does not seem to be supported for nested properties mutationThreshold . set ( 40 ) maxSurviving . set ( 3 ) } } } After the pitest pitestReportAggregate tasks execution, the aggregated report will be placed in the ${PROJECT_DIR}/build/reports/pitest directory. Integration tests in separate subproject It is possible to mutate code located in different subproject. Gradle internally does not rely on output directory from other subproject, but builds JAR and uses classes from it. For PIT those are two different sets of class files, so to make it work it is required to define both mainSourceSets and additionalMutableCodePaths . For example: configure ( project ( ’:itest’ )) { apply plugin: ’info.solidsoft.pitest’ dependencies { compile project ( ’:shared’ ) } configurations { mutableCodeBase { transitive false } } dependencies { mutableCodeBase project ( ’:shared’ ) } pitest { mainSourceSets = [ project . sourceSets . main , project ( ’:shared’ ). sourceSets . main ] additionalMutableCodePaths = [ configurations . mutableCodeBase . singleFile ] } } The above is the way recommended by the Gradle team , but in specific cases the simpler solution should also work: configure ( project ( ’:itest’ )) { apply plugin: ’info.solidsoft.pitest’ dependencies { compile project ( ’:shared’ ) } pitest { mainSourceSets = [ project . sourceSets . main , project ( ’:shared’ ). sourceSets . main ] additionalMutableCodePaths = project ( ’:shared’ )....