Code Coverage with JaCoCo — What to Measure and What to Ignore
Fast recall
Quick revision
Core answer
Whether the candidate understands what code coverage measures, its limitations, and what coverage targets are meaningful.
Chasing 100% coverage by testing getters, setters, and trivial code — this adds test maintenance cost without catching bugs.
Explain branch coverage vs line coverage, why coverage targets should differ by code type (80%+ for business logic, lower for configuration), and how JaCoCo exclusions prevent misleading metrics.
Interview-ready guide
Interview answer
JaCoCo measures test execution, not test quality. A test that calls every method but asserts nothing has 100% coverage and catches zero bugs. Coverage tells you what code ran during tests — not whether the tests actually verified anything.
Branch coverage is more valuable than line coverage. A method with if/else can show 100% line coverage while only testing the true branch. JaCoCo reports both separately.
My target: 80%+ for business logic, 60-80% for controllers and mappers, and exclude configuration classes and DTOs entirely. Chasing 100% means testing getters and generated code — maintenance cost with zero bug-catching value.
The most useful metric is coverage on new code — requiring 80% on changed files ensures new features are tested without forcing retroactive coverage of legacy code.
Code Coverage with JaCoCo — What to Measure and What to Ignore
Direct Answer
JaCoCo measures how much code is executed during tests. Line coverage counts executed lines. Branch coverage counts executed decision paths. Coverage measures test execution, not test quality.
Common Mistakes & Pitfalls
Chasing 100% coverage by testing getters, setters, and trivial code — this adds test maintenance cost without catching bugs.
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.