Engineering Practice
TDD: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the material stick.
Reconstruct the unit’s core arguments — test-first as design pressure, the boundary rule for doubles, the four property shapes, the spec-stability tradeoff, and why mutation score is the honest metric — without looking back at the lessons.
- 01A colleague says 'TDD is just about getting coverage up — I'll write the tests after, same result.' What's the senior counter?
- 02State the boundary rule for test doubles and the decisive question behind it.
- 03Name the four property shapes and give the situation each fits.
- 04Why does property testing find bugs an example suite with 94% coverage can't, and what makes generated tests trustworthy in CI?
- 05What two variables govern whether TDD pays off, and how does that distinguish design pressure from test-induced design damage?
- 06How can a module have 100% line coverage and a 67% mutation score, and how should a senior adopt mutation testing given its costs?
If you could reconstruct each answer from memory, you hold the unit’s spine: test-first is design pressure because you consume your own API first; the boundary rule (mock what you can’t run, real objects for what you own, assert state) tames doubles and the over-mocking trap; the four property shapes — round-trip, invariant, oracle, metamorphic — find the inputs your examples missed, with shrinking and seeds making failures debuggable; TDD’s 15–22% tax pays off in proportion to spec stability and code lifetime, so spike the unknown and tell pressure from damage; and mutation score is the honest metric because, unlike coverage, it can’t be satisfied by execution without assertion.