Code coverage MythBusters
summary
Claims: JaCoCo and IDE/JetBrains engines report different coverage numbers; zero coverage revealed tests didn't run (JUnit 4 vs 5/Vintage). Tools can be fooled: Mockito and final methods, switch statements vs switch expressions, and bytecode differences across Java 21/23 affect reports. Mutation testing with PIT shows surviving mutants that line coverage misses—PIT mutation testing finds weak assertions. Coverage instrumentation slows runtime (JetBrains engine ~4x slower in this benchmark) and can break JVM monitor/JIT behavior, risking Android failures.
AI-written summary · about
chapters (16)
- 0:00Introduction and speakers
- 2:08Supporting Ukraine
- 4:16Myth: 100% code coverage is mandatory
- 7:30Zero code coverage as a debugging tool
- 10:24Code coverage for debugging Eclipse plugins
- 11:05Demo: Best conference function
- 16:00Mocking pitfalls and switch expressions
- 20:02Demo: Perimeter calculation function
- 21:57Code coverage depends on compiler
- 23:01Comparing coverage tools: IntelliJ, JCoCo, Sonar
- 27:23Mutation testing with PIT
- 31:50Code coverage as a developer metric
- 34:01Code coverage performance impact
- 38:59Code coverage and JVM behavior
- 42:36Final myth: 100% coverage is achievable
- 44:17Key takeaways and summary
related talks
38mThe state of code coverage for Kotlin
42mThe state of code coverage for Kotlin
46mJava, Code Coverage & Their Best Friend: Bytecode
38mMutants to the rescue: How effective are your unit tests?
50mFrom jUnit to Mutation-Testing
43mMutation Testing
50mCode Coverage Instrumentation
45mJulius Mischok: Test Your Tests!
