testing-anti-patterns

Testing mock behavior means validating how mocks are called rather than verifying actual system functionality. Instead, structure tests to assert real behavior: call production code with test inputs, verify actual outputs or side effects, and use mocks only to isolate external dependencies you don't control. This ensures tests catch real failures.

Test-only methods bloat production with code that never runs in real use and create false test confidence. Instead, refactor production code to expose the behavior through its normal API, or test through public interfaces. This keeps production lean and tests honest about what actually executes.

Mock only external dependencies you don't own or can't control (APIs, databases, file systems). Before mocking, understand what the dependency does and why it matters. For code you own, prefer real objects or fakes. Mocking without understanding dependencies leads to tests that pass while production fails.

Testing mock calls verifies that code interacted with a mock correctly but says nothing about whether the real behavior works. Testing real outcomes asserts that given certain inputs, the code produces correct results or side effects. Real-outcome tests catch integration bugs; mock-call tests catch only broken mocks.

Identify which mocks mask real logic rather than isolate unavoidable external calls. Replace unnecessary mocks with real implementations or test doubles that behave like the real thing. Keep only mocks for true external dependencies. Run the refactored test against production code to confirm it catches real failures.

Signs include: tests pass but production breaks, many assertions on mock interactions rather than outputs, tests validate mock setup instead of behavior, and test-only production code. Apply the iron laws: never test mock behavior, never add test-only code, never mock without understanding. Refactor toward real-behavior validation.