unit-testing-principles

Mock only unmanaged dependencies like payment gateways, email services, and third-party APIs whose contracts you do not own. Managed dependencies such as your application's database should be tested with real instances or in-memory fakes in integration tests.

Stubs substitute incoming queries with canned data, while mocks verify outgoing commands were issued. Never verify calls on stubs, since that over-specifies the test and couples it to implementation details rather than observable outcomes.

Tests break on refactoring when they assert on implementation details like private state, internal call sequences, or mocked internal classes. Fix this by asserting only on observable behavior that any reasonable alternative implementation could satisfy.

Controllers are low-significance orchestration code best covered by integration tests with one happy path each. Unit-testing a controller usually requires mocking everything, producing low-value communication-based tests with weak regression protection.

Code coverage should never be a target because it does not measure regression protection. A suite with 100% coverage of trivial code and mocked interactions protects less than 60% coverage of high-significance domain logic tested at observable boundaries.