unit-testing

Write a failing test that reproduces the bug before touching the fix, asserting the correct behavior. Confirm it fails for the expected reason, apply the fix, verify it passes, and keep the test permanently as a regression guard.

A stub returns canned answers, a fake is a working simplified implementation like an in-memory repository, a spy records how it was called, and a mock has pre-programmed expectations about interactions. Prefer fakes over mocks whenever the dependency is cheap to implement in-memory.

Mock or fake only at architectural boundaries: network calls, databases, filesystem, wall-clock time, randomness, and third-party SDKs. Do not mock cheap in-process collaborators, since over-mocking turns tests into implementation mirrors that pass even when logic is wrong.

Skip trivial getters, framework wiring, generated code, pure configuration, thin pass-through wrappers, and third-party library internals. Focus testing effort on business logic, state transitions, boundary conditions, error handling, and anything that has caused a production bug.

This usually means tests assert trivial conditions or mock away the exact behavior they claim to verify. Assert on observable outcomes like return values and saved state rather than call shapes, and exercise real collaborators where they are cheap and deterministic.

No. Coverage measures which lines executed, not whether assertions verify correct behavior. Use coverage reports as a diagnostic to find untested business-critical branches, not as a target, since high coverage with weak assertions still ships regressions.