The state of code coverage for Kotlin
summary
Team coverage target drops from 95% to 85% after switching to Kotlin; concrete reasons appear: bytecode-generated null checks, string-switch hash checks, inlining and optimizer removals, and R8 plus coverage instrumentation breaking structured locking. Reports compare JaCoCo, JetBrains coverage engine and PIT mutation testing (PIT shows surviving mutants missed by line coverage). Measured overhead: baseline 57s, JaCoCo ~1m20s, JetBrains ~1m23s, PIT initial run ~1h20m7s. A commercial plugin Arcmate claims better Kotlin filtering.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 2:01Understanding code coverage
- 4:04Evolution of coverage tools
- 6:45Tooling overview
- 9:43Analyzing coverage behavior
- 18:34Inline functions challenges
- 24:18Coroutines and testing
- 26:21Android and composables
- 29:26Observer effects and risks
- 33:57Performance overhead
- 35:46Conclusion and future
