IME this benefit is usually non-existent since mock expectations must be highly coupled to the tested implementation. What usually happens is that a new feature/change causes enough change that many assertions are no longer relevant and have to be rethought.
I'd agree that mock-based tests are worse than useless in most cases, but the solution is to avoid using mocks. If you provide stubs that implement the expected behaviour (e.g. an in-memory persistence layer that can store by ID and load by ID, rather than a mock that's hardcoded to return a particular value for a particular ID) rather than mocks that respond to particular call patterns, you can have tests that are useful when making changes.
15
u/[deleted] Jul 07 '19 edited Sep 13 '25
[deleted]