Should I practice "mockist" or "classical" TDD?

Question

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 question "So should I be a classicist or a mockist?", but he admits that he has never tried mockist TDD on "anything more than toys." So I thought I'd ask the question here. Good answers may repeat Fowler's arguments (but hopefully more clearly) or add arguments that he didn't think of or that others have come up with since Fowler last updated the essay back in January 2007.

Answer 1

I don't think you need to choose one over the other. Both have their advantages and disadvantages and both are tools for your toolbox. "Mockist" tdd makes you a bit more flexible in what you can test while classical TDD makes your tests a bit less brittle because they tend to look more at the input/vs output instead of looking at the actual implementation. When doing mockist unit testing I seem to have more tests break when changing the implementation.

I try to use classical tdd whenever possible (although i often use a mocking framework to set up the stubs quickly). Sometimes I notice I start testing too much at one time or i need too many objects to set up a test. That's when mockist testing can often help you set up smaller tests.

This is all quite abstract so I hope i make sense