mutationThreshold as 100 is not guaranty that all classes is covered by 100%
steps to reproduce
$ git clone [email protected]:checkstyle/checkstyle.git
$ git checkout 3df996acc3bfc8072bcb5ce50009add08c3104dc
$ mvn -Ppitest-checks-annotation,no-validations clean verify org.pitest:pitest-maven:mutationCoverage -Dverbose=true

Unfortunately it could lead to leek of incomplete test even on CI level is demanded to be 100% for Mutation Coverage <mutationThreshold>100</mutationThreshold> .
Expected: when some class is less then 100%, summary mutation coverage should be less then 100% and to have build failed if <mutationThreshold>100</mutationThreshold> present in config.
the same problem for coverageThreshold, 100 in config does not trigger build failure when come class is covered a bit lower than 100.
Post processing of report by "grep/...." is required to enforce 100 always, and have no leak.
@romani I have the same issue sometimes. My team is always putting the threshold to 100.
I found a round in the source code of the plugin, which put the percentage to 100% even if you have mutant still alive. e.g : you have 500 mutant generated, but 499 killed, the pluging compute a Math.round((100 / 500) * 499) = Math.round(99.8) = 100
I don't know for the coverageeThreshold. I will check later
I'm preparing a PR to fix this
Is it same as https://github.com/hcoles/pitest/pull/638 ? And https://github.com/hcoles/pitest/pull/776
Ohh sounds like there are conflict about rounding down and up :( My solution is not exactly the same, but I will put some comments on these one. Thanks.
@romani as my #638 was finally merged into 1.13.2, you can check whether it also fixes your issue which I assume it does. I would have checked, but by using your reproduction instructions I just get compilation errors.
@Kevin222004, please send PR to update pitest to latest version
I closing this issue, we will open new issue is something is required to be improved.
Ah, no, now I can say my PR was not related. :-D
But probably the same logic should be used:
#1221 should finally fix it hopefully though
It was merged, so next release after 1.14.1 should fix it.