I\'ve read (and re-read) Martin Fowler\'s Mocks Aren\'t Stubs. In it, he defines two different approaches to TDD: \"Classical\" and \"Mockist\". He attempts to answer the
The question about mockist or classic tdd is very much about what part of your application you're testing. If you have a "standard" layered architecture (like DDD for example) the domain layer is usually suited for classic tdd where you unit test by setting up the object under test, call a few methods and check the result and/or the state.
On the otherhand when you're testing application services, controllers or presentation logic which all do more coordinating work, mocking or stubbing is often needed to get good tests. My experience is also that these classes tend to call other layers (webservice, datalayer,...) which you really want to mock or stub. These unit tests also need more setup code so you should only mock when you have to.
My advice is to go classic whenever you can and mock when you must.