Explain JaCoCo's coverage metrics — instruction, line, branch, method, and complexity — and why line coverage alone can be misleading.

## Why there are multiple metrics A "unit" of coverage can be defined at different granularities. JaCoCo computes several **counters** simultaneously, each answering a slightly different question about what the tests exercised. Understanding each prevents you from trusting a single, potentially flattering number. ## Instructions When Java compiles, each statement becomes one or more **bytecode instructions** (e.g. load a value, add, invoke a method, return). The **instruction counter** is JaCoCo's *finest-grained* and most reproducible metric, because it does not depend on source formatting — it only depends on compiled output. A method is fully instruction-covered when every bytecode instruction in it ran. ## Lines A **line** is a line of your source file. JaCoCo maps groups of instructions back to the source line they came from (using debug info in the `.class` file). A line is: - **green / fully covered** — all its instructions ran, - **yellow / partially covered** — some but not all ran (e.g. one branch of a condition on that line), - **red / missed** — none ran. Because lines depend on how you format code, the same logic split across one line vs. three lines yields different line counts. (Line info requires the class be compiled with debug data; without it, line coverage is unavailable but instruction coverage still works.) ## Branches A **branch** is one outgoing path of a *decision point*. Decision points are `if`, `switch`/`case`, the ternary `?:`, and the short-circuit operators `&&` and `||`. A simple `if (x)` has **two** branches: the path taken when `x` is true and the path when it is false. The **branch counter** records how many of these arms were exercised. This is the metric that catches the classic trap: ```java int classify(int n) { if (n > 0) return 1; // one source line, TWO branches return -1; } ``` A single test with `classify(5)` executes the line `if (n > 0) return 1;`, so **line coverage = 100%** for that line — yet the `n <= 0` branch (the `return -1`) was never reached. **Branch coverage** would show 50% (1 of 2 branches) and the line would render **yellow**, exposing the gap. You need a second test, e.g. `classify(-3)`, to cover both branches. ## Methods and classes The **method counter** records whether each method was entered at least once; the **class counter** records whether *any* method of a class ran (so the class was loaded and used). These are coarse: entering a method once says nothing about its internal branches. ## Cyclomatic complexity **Cyclomatic complexity** is a number measuring how many *linearly independent paths* run through a method — intuitively, the number of decision points plus one. A straight-line method has complexity 1; each `if`/`case`/loop condition adds 1. JaCoCo reports both total complexity and the portion *covered*, which approximates how many test cases are still needed to exercise all paths. High complexity with low covered-complexity flags risky, under-tested logic. ## Why line coverage alone misleads Line coverage answers "did this line run at all?" — not "did I test every outcome of the decisions on it?". Conditional-dense code (guard clauses, validation, `&&` chains) can show high line coverage while leaving half the logical paths untested. **Branch coverage** (or instruction coverage, which is even finer and immune to formatting) gives a truer picture. Mature teams therefore set thresholds on **branch** and/or **instruction** counters, not lines, particularly for business-rule and parsing code. ## Practical summary - **Instruction** — finest, formatting-independent → best for stable thresholds. - **Branch** — exposes untested true/false paths → best for conditional logic. - **Line** — readable but formatting-sensitive and branch-blind. - **Method / Class** — coarse "was it touched" signals. - **Complexity** — risk indicator; covered vs. total estimates remaining test effort.