3 ms·

> Ask yourself the question "What tends to get mocked?" Answer: every collaborator of the object under test, so that only the tested object is actually having

> Ask yourself the question "What tends to get mocked?" Answer: every collaborator of the object under test, so that only the tested object is actually having its implementation exercised. All other objects that it needs to talk to — database connections, network sockets, or whatever — are replaced with mocks, and the test subject’s interactions with those mocks are verified, so that a) we have confidence that the tested object is interacting with its collaborators in the expected way, and b) the test itself doesn’t depend at all on the actual behaviour of those collaborators’ implementations, which behaviour should be explicitly exercised elsewhere. That’s the opposite of coupling. I don’t understand where your answer comes from or what it means.

mpdehaan2 12y ago
I view this as definitely enforcing coupling. The issue is that you should want to make it very easy to change the API signature of internal components. Mock objects can tend to reinforce internal coding choices when things that are not a public interface, or a service boundary, are mocked out. If you're mocking at this level, there is a potential for refactoring of intra-class API contracts to become much harder to change. Thus, it would be better IMHO to mock out only meaningful service boundaries, and concentrate testing at the public contracts. You can still get very strong coverage, but you're just thinking about a different level of inputs.
ollysb 12y ago
The point more accurately is that coupling to the interface used to communicate with your collaborator I.e. If you were to refactor the way that the test object communicates with it's collaborator (without changing it's external behaviour) you are now forced to update the mocks. If the collaborator is only used within your test object and nowhere else in your system the communication between them doesn't need to be pinned down, the test should just test both of them at the same time. This is the difference between a white box test (where your mocking has to expose implementation details) and blackbox testing (where you can refactor without breaking tests).

mpdehaan2 12y ago

I view this as definitely enforcing coupling. The issue is that you should want to make it very easy to change the API signature of internal components. Mock objects can tend to reinforce internal coding choices when things that are not a public interface, or a service boundary, are mocked out. If you're mocking at this level, there is a potential for refactoring of intra-class API contracts to become much harder to change. Thus, it would be better IMHO to mock out only meaningful service boundaries, and concentrate testing at the public contracts. You can still get very strong coverage, but you're just thinking about a different level of inputs.

ollysb 12y ago

The point more accurately is that coupling to the interface used to communicate with your collaborator I.e. If you were to refactor the way that the test object communicates with it's collaborator (without changing it's external behaviour) you are now forced to update the mocks. If the collaborator is only used within your test object and nowhere else in your system the communication between them doesn't need to be pinned down, the test should just test both of them at the same time. This is the difference between a white box test (where your mocking has to expose implementation details) and blackbox testing (where you can refactor without breaking tests).