Open-source libraries are quietly load-bearing. Apache Commons CLI parses command-line arguments for countless Java tools, so a subtle regression there ripples outward to everyone who depends on it. I set out to make it genuinely regression-proof — not "has tests," but provably resistant to breakage.
Coverage is a floor, not a goal
It's easy to hit a high line-coverage number while your tests assert almost nothing — they execute code without checking the result. To measure whether the tests actually catch bugs, I leaned on mutation testing with PIT: it injects small faults (flip a condition, change a return) and checks whether a test fails. A surviving mutant is a hole in your suite that line coverage will never reveal.
The numbers
I engineered 1,938 test methods producing 3,965+ assertions across 36 production classes, reaching 98% line/instruction and 95% branch coverage. That included 36 parameterized tests, 11 regression classes targeting known CVE-adjacent bugs, and 31 EvoSuite-generated suites — all validated across six JDK versions (8, 11, 17, 21, 25, and 26-ea) so a passing build means passing everywhere.
Make quality non-negotiable in CI
Tests only protect you if they can't quietly erode. I wired build-enforced JaCoCo thresholds (the build fails if coverage drops below target) into a six-tool quality pipeline — JaCoCo, PIT, SpotBugs, Checkstyle, PMD, and Apache RAT — plus four GitHub Actions workflows including CodeQL security scanning and an OpenSSF Scorecard audit. Quality becomes a gate, not a hope.
What I took away
- Mutation score > coverage %. It's the honest signal of suite strength.
- Enforce gates in CI. If a regression can't merge, it can't ship.
- Test across versions. "Works on my JDK" isn't an invariant.
This is the kind of rigor I bring to production code, not just open source — features that ship and keep working.