Code coverage and its pitfalls
understanding coverage as a signal, not a goal.
it measures executed lines, surfaces untested paths, and guides where to add tests.
treating 100 percent as proof of correctness or writing assertion-free tests just to inflate…
What's really being asked
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's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
A module reports 100 percent line coverage. What does this guarantee about its correctness?
- a.The tests will never become flaky
- b.All edge cases and branches are fully verified
- c.The module is free of logic bugs
- d.Every line was executed, but not that outputs were asserted correctCorrect
Why? this is the answer
Coverage only confirms lines executed during tests; tests can run code without asserting anything meaningful. It says nothing about branch completeness, logic correctness, or flakiness.
Just read this? Test yourself on what you have been reading.
Read the original → developer.apple.com
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ios — each one lists the topics its interview covers.
See open roles