What is Mocking vs Stubbing?

Gerard Meszaros defined five types of test doubles: dummies (never used, just fill parameters), fakes (working implementations with shortcuts, like an in-memory database), stubs (return pre-programmed responses), spies (record calls for later verification), and mocks (pre-programmed with expectations that are verified during the test). In practice, most teams use "mock" loosely to mean any test double.

Stubs are state-based: you set up a return value and assert on the outcome of the system under test. "When the payment gateway is called, return success. Then verify the order status is confirmed." Mocks are interaction-based: you assert that a specific method was called with specific arguments. "Verify that the email service was called exactly once with the user's email and the order confirmation template."

Over-mocking is the most common pitfall. When tests mock every dependency, they become coupled to implementation details rather than behavior. A refactor that changes internal method calls without changing behavior breaks all the mocks. The guideline is: mock at architectural boundaries (APIs, databases, third-party services) and test internal logic with real objects whenever possible.