Code coverage and its pitfalls

WHAT THIS TESTS The question separates engineers who understand testing intent from those who chase vanity metrics. The interviewer wants you to articulate that coverage measures execution, not correctness.

WHAT THIS TESTS Xcode gathers coverage when you enable it in the test scheme, instrumenting the build to record which lines and branches executed during the test run. The report shows percentages per file and highlights unexecuted lines in the editor, letting you spot error branches, guard else paths, and switch cases your tests never reached.

A GOOD ANSWER COVERS Use coverage to find blind spots: low coverage on a payment or parsing module is a real signal to write tests there. Combine line coverage with branch awareness, since a line can execute while a conditional branch stays untested. Treat it as one input among code review and design.

COMMON WRONG ANSWERS Claiming high coverage guarantees correctness. A test that calls a function but asserts nothing raises coverage while proving nothing. Writing tests to cover trivial getters and synthesized initializers inflates the number without value. Mandating a hard threshold can incentivize gaming rather than meaningful testing.

LIKELY FOLLOW-UPS What is the difference between line and branch coverage? Would you ever exclude generated code from coverage? How do you balance a coverage gate in CI against developer friction?

ONE CONCRETE EXAMPLE A function has an if-let that handles a nil case by logging and returning early. A test that only passes a valid value executes the success line, reporting high line coverage, yet the nil branch never runs and a regression there ships silently. Reading the coverage gutter reveals the unexecuted else, prompting a second test for the nil path. Here coverage guided a real improvement, but the lesson is the assertion matters more than the percentage.