Some time ago I read, on a Stack Overflow answer that I can't find, a sentence that explained that you should test public APIs, and the author said that you should test interfaces. The author also explained that if a method implementation changed, you shouldn't need to modify the test case, as doing this would break the contract that make sure the system under test works. In other words, a test should fail if the method doesn't work, but not because the implementation changed.
This called to my attention when we talk about mocking. Since mocking relies heavily on expectation calls from system under test's dependencies, mocks are tightly coupled with the implementation rather than the interface.
While researching mock vs stub, several articles agree that stubs should be used instead of mocks, as they don't rely on expectations from dependencies, meaning the test need no knowledge of the underlying system under test implementation.
My questions would be:
- Do mocks violate the open/closed principle?
- Is there something missing in the argument in favor of stubs on the last paragraph, that make stubs not so great vs mocks?
- If so, when would be a good use case to mock and when would be a good use case to use stubs?