- #445 Raise minimum java version to 8
- Switch to ASM 6.1.1
- #448 Aggregate report based on module
- #462 Escape test names in coverage xml
As of this release pitest will no longer run on JVM < 8, but pre Java 8 bytecode continues to be supported.
Commons-codec is no longer required on the classpath when running via Ant or the command line.
#433 - Aggregate reports via maven (thanks @rchargel)
#438 - Filter tests at method level (thanks @ftrautsch)
#439 - Primitives return mutator doesn't handle bytes
#380 - Remove reliance on xstream for improved java 9 support
#414 - Replace xstream history store (thanks @kiftio)
Note when upgrading that history files generated by previous releases are not compatible with 1.3.2 and above.
The removal of xstream eliminates all access warnings under java 9. If running from the commandline or ant commons-codec is now required on the tool classpath.
Small release for issue #434 which, although it had no functional effect, was kind of annoying.
- #196 - Raise minimum java version to 7
- #425 - Broaden for-each detection
- #428 - Add excludedTestClasses parameter
- #379 - Remove support for mutating static initializers
- #432 - Add export plugin functionality into pitest
- #427 - Better return values mutators
- #429 - Simplify test api
428 changes the existing behaviour of the excludedClasses filter. Previously this excluded classes from both being mutated and run as tests which may require changes for some people when upgrading.
Test plugin selection is no longer automatic for projects using testng - the test plugin must no be explicitly set using the new
testPlugin parameter. This defaults to "junit" unless the junt5 plugin is on the classpath in which case it will be defaulted to "junit5".
New mutation operators
The intention is to change the mutation operators that are active by default in the next release, replacing the RETURN_VALS mutator with the improved set introduced in this release.
The new proposed defaults can be used in this release by setting the
mutators parameter to NEW_DEFAULTS.
- #407 - SCM goal cannot be run from within module (thanks @sbuisson)
- #256 - Inline style violate Content Security Policy (thanks @kiftio)
- #403 - No css in the html report viewed from jenkins (thanks @kiftio)
- #409 - Mutate based on changes across branched (thanks @sbuisson)
- #418 - Avoid for loop increments
- #424 - Avoid for each code
- #389 - Widen matching of implicit null checks
Bugfix release for #367
Some projects experienced issues resolving core java classes during static analysis phase with 1.2.1. Although this seems to only affect a small number of projects it is recommended that everyone upgrade.
#347 - Avoid autogenerated code (e.g by lombok) anotated with @generated
#285 - Avoid compiler generated conditionals in switch on string. (thanks @Kwaq)
#218 - New "naked receiver" / method chain mutator. (thanks @UrsMetz)
#354/#356 - New extension point plus changes to reduce cost of random access to bytecode for static analysis
#353 - Improved static initializer code detection
#364 - Filter infinite loops via static analysis
#365 - Configuration system for plugins
Filtering by annotation
The new annotation filtering will work only with annotations that have class or runtime retention. Annotations such as
javax.annotation.Generated are invisible to pitest as they have only source retention.
By default pitest will not create mutations in any methods or classes annotated with annotations named Generated, CoverageIgnore or DoNotMutate, regardless of the package name.
If you are using Lombok it can be configured to add a Generated annotation by setting
lombok.addLombokGeneratedAnnotation = true
in the Lombok configuration (not pitest's)
If the default annotations are not sufficient custom annotations can be configured using the new feature config system.
In maven pass
<feaures> <value>+FANN(annotation[com.example.MyAnnotation1] annotation[com.example.MyAnnotation2])</value> </features>
And the custom annotations will be ignored.
Filtering of annotations can be disabled entirely by setting
<features> <value>-FANN</value> </features>
Infinite loop detection
Pitest has always been able to deal with infinite loops, but each one it encounters costs several seconds of processing time.
As a performance enhancement pitest can now detect some types of infinite loop via static analysis and remove these mutations from the analysis.
Most users will not notice a performance improvement as the types of infinite loop detected are not generated by the default mutator set. If you have the REMOVE_INCREMENTS mutator or NON_VOID_METHOD_CALLS mutator enables you may however see a significant reduction in both the number of generated mutants and the analysis time.
Improvements will be made to this system in future releases.
To disable infinite loop filtering pass the feature name with a
- in the features section of the config.
- FINFINC - Filters mutations to increments that may cause infinite loops
- FINFIT - Filters mutations that may cause infinite loops by removing calls to iterator.next
As discussed briefly in the above sections this release provides a new way to configure some aspects of pitest's behaviour.
Several previously hard coded behaviours can now be configured in this way
- FINFINC Filters mutations to increments that may cause infinite loops
- FFBLOCK Filters mutations in code duplicated by finally block inlining
- FSTATI Filters mutations in static initializers and code called only from them
- FTRYWR Filters mutations in code generated for try with resources statements
- FSTATINIT Filters mutations in static initializers and code called only from them
- FLOGCALL Filters mutations in code that makes calls to logging frameworks
- FINFIT Filters mutations that may cause infinite loops by removing calls to iterator.next
- FANN Filters mutations in classes and methods with matching annotations of class or runtime retention
If pitest is run with verbose logging enabled a list of enabled and disabled features will be printed.
To enable a feature specify it with a leading + in the features config section.
To disable a feature specify it with a leading - in the features config section.
#318 - Separate main process code from code sharing client classpath
#295 - Ignore abstract TestNG tests
#215 - Automatic selection of target classes for maven
#314 - Do not fail for maven modules without tests or code
#306 - Do not fail when only interfaces are in changeset
#325 - Anonymous class in Spock test causing error
#334 - Compatibility with recent TestNG releases
#335 - Incorrect coverage with powermock