Engineering Practice
TDD: multiple-choice review
Crux Multiple-choice synthesis across the TDD unit — design pressure, the boundary rule for doubles, property shapes, the spec-stability tradeoff, and mutation score as the honest metric.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one is a decision a senior makes under real constraints — a fragile suite, an unknown vendor, a green CI sitting on a 67% mutation score — not a definition to recite.
Goal
Confirm you can connect the unit’s spine: test-first as design pressure, the boundary rule that tames doubles, properties over examples, when TDD’s tax is worth paying, and mutation score as the metric coverage can’t fake.
Quiz
Completed
You write a test first and find you must construct four collaborators — DB, payment, email, flags — just to exercise one cancel-order rule. What is the test actually telling you?
Heads-up That silences the exact signal TDD just gave you. A test needing four mocks is testing a god object; the mocks paper over the design problem and lock the bad shape in. The friction was the point.
Heads-up Hard-to-test almost always means hard-to-change. Declaring it untestable ships the god object untouched and unguarded; the difficulty is information about the design, not a reason to drop the discipline.
Heads-up Coverage is a side effect, not the goal. Test-first's distinctive value is the design feedback from consuming your own API as the first caller — which this hard-to-construct object just delivered.
Quiz
Completed
A PriceCalculator uses a pure TaxRule you own and a third-party CurrencyApi over HTTP. How should you double each for a robust unit test?
Heads-up Mocking the pure TaxRule you own is over-mocking — there is nothing to isolate, and asserting its calls pins the test to internal structure. Worse, stubbing the tax result means the real math is never verified and a pricing bug can ship green.
Heads-up A live network boundary makes the test slow, flaky, and dependent on a third party's uptime and a changing rate. Network boundaries are exactly what you must double — this loses determinism for no benefit.
Heads-up This inverts the boundary rule. You throw away the math you most want to test and reintroduce the flakiness you should have removed — doubling what you own and trusting what you don't.
Quiz
Completed
A money formatter has 94% coverage and eight months of green CI, then double-charges a customer on a value ending in .005. Why did every example test miss it, and what would have caught it?
Heads-up The bug lived in covered lines: every line ran with round numbers. Bugs hide in untried inputs through fully-covered code, which is exactly what coverage cannot see.
Heads-up More examples in the same style re-test the cases already imagined. The gap is defined by what nobody thought to type, so only generated input over an invariant closes it.
Heads-up Mutation testing attacks the output side — missing assertions — not the input side. The .005 gap is an un-enumerated input, which is precisely what property generation covers.
Quiz
Completed
A senior insists on full TDD for a two-day spike to evaluate an unfamiliar vendor API and decide whether to sign. Why is this the wrong call?
Heads-up Speed is not the issue. The spec is unknowable up front, so test-first specifies behavior you're about to learn is wrong — the discipline is being applied to the one situation it punishes.
Heads-up It can be tested once you know its real shape. The point isn't untestability — it's that pinning a spec before you understand it is wasted front-loading on disposable code.
Heads-up Live tests against an unfamiliar third party are slow, flaky, and rate-limited, and you still don't know the correct behavior to assert. You'd fight test infrastructure instead of answering the sign/don't-sign question.
Quiz
Completed
A billing module shows 100% line coverage but a 67% mutation score, with a surviving '>' → '>=' boundary mutant. How do you read this?
Heads-up They measure different things — execution versus detection. A line can run in every test while no assertion would fail on a wrong result, so 100% coverage and a 67% mutation score are fully consistent.
Heads-up That discards the one metric that just proved the gate is hollow. Coverage can't see the missing boundary assertion; turning off the honest metric to preserve the misleading one is backwards.
Heads-up Equivalent mutants make sub-100% expected and full-repo runs take hours. The goal is killing meaningful survivors on critical modules, not a flawless number everywhere.
Quiz
Completed
Across the unit, what is the through-line that distinguishes a test suite that is an asset from one that is a liability?
Heads-up Coverage measures execution, not detection — you can hit 100% and still miss a third of injected bugs. A trustworthy suite is defined by what it asserts, not how many lines it runs.
Heads-up Over-mocking pins tests to call structure: they break on harmless refactors and stay green on real bugs because stubbed results are never checked. Isolation for its own sake manufactures fragility.
Heads-up Indirection that serves the test rather than the user is damage, not a virtue. The skill is heeding pressure that reveals a real coupling smell and refusing ceremony added solely to satisfy a test.
Recap
The unit’s spine is one judgment loop. Test-first is design pressure — a hard-to-construct object is the design review, not an obstacle to mock around. The boundary rule tames doubles: mock what you can’t run, use real objects for code you own, assert state. Example tests cover only inputs you imagined, so properties generate the rest and shrink failures to a minimal counterexample. TDD’s tax (15–22%) pays off in proportion to spec stability and code lifetime — spike the unknown, then rebuild. And mutation score is the honest metric: coverage proves a line ran, a survived mutant proves a test would have missed the bug. Through all of it, couple to behavior, never to structure.