As a "mockist" TDD practitioner, should I mock other methods in the same class as the method under test?

Question

After reading Martin Fowler's Mocks Aren't Stubs, I've discovered I've been practicing TDD in the "mockist" fashion.

But I'm wondering if even in mockist TDD if one can take mocking too far.

Here's an updated example in Python-style pseudo-code:

def sync_path(self):
    if self.confirm_or_create_connection():
        self.sync(self.dirpath)

The confirm_or_create_connection() method creates a connection to a server.

I tested a method similar to this in two tests, both of which mock confirm_or_create_connection() and sync() (even though they're both methods in the same class). In one test the mock confirm_or_create_connection() returns True and the test confirms that sync() was called, and in the other the mock confirm_or_create_connection() returns False and the test confirms that sync() was not called.

Is this reasonable? Or should I mock the objects that confirm_or_create_connection() and sync() call? (I have other tests of both of these methods that already do this.)

Please don't answer the question by explaining that I should be practicing "classical" TDD instead. That's an answer to another question: Should I practice mockist or classical TDD?

Answer 1

The technique is called "mock objects", not "mock methods" for a reason. It encourages designs that divide the system into easily composed, collaborating objects and away from procedural code. The aim is to raise the level of abstraction so that you mostly program by composing objects and rarely write low-level control flow statements.

Answer 2

Personally I think that mocking on self is almost always a code smell. It's testing the implementation rather than the behavior.