Question bank — Code coverage — line, branch, path coverage

False. Coverage records only that a line ran; a test can execute it and assert nothing, so "tested" (checked) and "executed" (ran) are different things.

True. Taking every true/false outcome of every decision forces control flow through every reachable line, so all lines must have executed at least once.

False. One test can run every line yet only take the True side of an if; the False outcome stays untaken, so branch can sit at 50% while line is 100%.

False. Branch (decision) coverage tracks the whole condition's T/F; condition coverage tracks each boolean sub-term's T/F. a and b is one decision but two conditions.

False. Branch coverage only needs each outcome to occur at least once, not in every combination — that stronger demand is path coverage.

False. A loop that can run 0..k times or many sequential ifs give exponentially many (or with unbounded loops, infinitely many) feasible paths, so full path coverage is often infeasible.

True. With zero decisions there are no separate outcomes to count, so "lines run ÷ lines total" and "branch outcomes taken ÷ total" describe the same straight-line code.

False. Coverage bounds your ignorance (what you never ran), not your bug count; tests can run everything and still assert nothing, catching zero defects.

The error is equating execution with verification. Coverage says the code ran; correctness needs assertions that check the results — mutation testing is the honest follow-up question.

Wrong: grade(60) only takes the True outcome, so branch coverage is 1/2 = 50%. You also need an input like grade(40) to take the False outcome.

Wrong: they create $2^2=4$ paths (TT, TF, FT, FF). Two ifs create two branch outcomes each but their combinations — the paths — multiply, not add.

Wrong: condition coverage needs each sub-term (a and b) to be independently True and False. Short-circuiting means when a is False, b is never even evaluated, so a naive pair of tests can leave b's outcomes untested.

Wrong: a compound condition sits on one line, so running that line once marks it fully line-covered while user.active may never have been evaluated due to short-circuiting.

The subsumption direction is right but the cost claim is backwards: path is stronger and far more expensive ($2^n$ paths), so branch is the cheap subset of path, never the other way round.

Because one if line contributes a single line to count but two branch outcomes (True and False), so decisions inflate the branch total beyond the line total.

Branch coverage needs each outcome once, satisfiable with tests TT and FF; the specific combination TF (a distinct path) is never exercised, so a bug living only there stays invisible.

Because low coverage guarantees undertested code (you know you skipped it), but high coverage does not guarantee good tests — so it can only certify the bad case, hence a bound on what you're ignorant of.

In a and b, when a is False the language stops and never evaluates b, so b's True/False outcomes may never be recorded even though the line ran.

MC/DC (Modified Condition/Decision Coverage) requires each condition to independently flip the decision's outcome, catching short-circuit and compound-logic gaps that decision coverage masks — critical where a single missed case can be fatal.

Past a point extra coverage just re-runs code without new checks; assertions are what actually detect wrong behaviour, so they convert "ran" into "verified."

It still reports the lines and branches that executed before the crash as covered, because instrumentation records execution regardless of whether assertions were reached.

It caps your achievable line/branch percentage below 100% no matter how many tests you write, because there is no input that reaches it — a signal to delete the dead code or fix the logic gating it.

Branch coverage is undefined-or-trivially-100% because there are zero decisions; with no branches to take, the metric has nothing to divide and the code is fully "covered" by any call.

No; the 0-iteration case is a distinct branch outcome (the loop condition being False on entry), so you also need an input that skips the loop entirely for full branch coverage.

They collapse to the same thing: straight-line code has one path, no branch outcomes to split, so a single execution gives 100% on all three levels simultaneously.