Regression in 1.9.11 -> 1.10.1 : line coverage stats >100%
See original GitHub issueDependabot wants to update my project from 1.9.11 to 1.10.1, but the PR is failing as line coverage on the first subproject has dropped from 100% to 98% according to the build output.
When I try to recreate the failure locally the generated report shows an overall line coverage stat of 106%, and even 133% in one class. Predictably enough, the >100% coverage class reports show no uncovered lines and no obvious weirdness. I think my tests are pretty good, but they’re not that good.
Hopefully others can recreate this result by:
git clone https://github.com/Mastercard/flow.git && cd flow
mkdir -p api/target && touch api/target/mutate
mvn test-compile
Cheers!
Issue Analytics
- State:
- Created 10 months ago
- Comments:7 (7 by maintainers)
Top Results From Across the Web
Issues · hcoles/pitest - GitHub
Regression in 1.9.11 -> 1.10.1 : line coverage stats >100% ... Pitest XML report does not contain data about uncovered lines.
Read more >Production Function and Regression Methods Using R
One limitation of H is that it focuses only on the “influence” of the X matrix on the regression line while ignoring that...
Read more >Apache Subversion < 1.9.11 / 1.10.x < 1.10.5 / 1.11.x / 1.12.x...
The remote host has an application that is affected by multiple vulnerabilities. Description. The installed version of Subversion Server is prior to 1.9.11, ......
Read more >gretl changelog - SourceForge
the final regression in "coint" (Engle-Granger test) could end up using a ... and build with openmp support 2012-11-21 Version 1.9.11 (2012d) [Back...
Read more >Introduction to Mathematical Statistics - minerva
topics in statistics. Chapter 9 contains inference for normal theory methods for basic analysis of variance, univariate regression, ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Fortunately looks to be a simple issue. Lines are being double counted when generating the threshold if they’re included in the bytecode more than once. The compiler would do this for finally blocks, and perhaps in some other scenarios.
It also seems that the old html report code is calculating this stuff seperately, which seems less than ideal.
Will poke around for a bit to see if anything else looks broken, then produce a release shortly.
@therealryan Ok, looks like something was badly messed up with the thresholds during the 1.9 -> 1.10 refactor, which is a little embarassing. Thanks again for reporting, hopefully this was stupidity confined to a single place rather than something wide spread.