unit-testing

Topics in the source

• Unit testing
• 1. Decide what deserves a test
• 2. Pick the seam
• 3. Enumerate cases before writing any
• 4. Write tests that survive refactoring
• 5. Testing code that was not built for it
• 6. Keep the suite trustworthy

A test earns its place by failing when something breaks and staying quiet otherwise. A test that never fails is documentation with a runtime cost; a test that fails on every refactor is a tax. Both get deleted eventually, and the second one takes the good tests' credibility with it. Coverage is not the goal. Coverage measures which lines ran, not whether anything was checked — a suite that executes everything and asserts nothing scores beautifully and catches nothing. In descending order of value: 1. Logic with branches — conditionals, loops, calculations, parsing, state transitions 2. Anything that has broken before — bugs cluster; a fixed bug without a test will return 3. Boundaries — where data is validated, converted, or crosses a system edge 4. Contracts other code relies on — a public API's shape and its documented failure modes Not worth it: generated code, thin pass-throughs, framework behaviour, getters, and anything where the test would restate the implementation line for line. Done when: you can say why each planned test exists, in terms of a failure it would catch. Test at the smallest stable interface that exposes the behaviour, not necessarily the smallest unit. A pri

This is an excerpt. Refer to the complete source and its current requirements.