Posted: Sat Aug 20, 2005 5:27 pm
I think I'm balking at something close to the "Law/Suggestion of Demeter". Its one thing to use expectations/mocks to dictate how a given outside class interoperates with the test under discussion. Its something else to use the expectations/mocks to say how the class interoperates with the classes one more step away.McGruff wrote:Interaction-based tests are by their nature intrusive but that's the point. You're trying to figure out the interfaces of neighbouring objects in the design, and how these will be used by the object under test.I think I can rip out all the tally's and all the expectCallCounts as that's not really important here. I guess I really only needed stubs. If I do that, I think its less instrusive.
Stubs just return values on demand but mocks also allow you to set expected call counts and the arguments expected at each method call. The expectations are important: without them, it wouldn't be TDD. With expectations, the test case verifies that the primary object interacts with the mock in a specific way. Stubs don't do this. There's no way to assert that a mock foo() method is being called with the correct number of arguments, or how many times it's called in total.
In this case. why should the handler test care if the handler's implementation invokes the getUserName method once (and caches it) or twice, etc. The test should test the the "interface" of the class not its detailed implementation, right? Doesn't testing the imeplementation as deep as mocks do promote a tigher coupling than might be desired?