They didn't highlight the key property of a project for when tdd works and when it doesn't: when you know the requirements with clarity (compilers, stacks, etc) it is possible to use tdd since the tests will map back to well understood requirements. But when you don't (like building a website with fussy browsers, or writing a log file parser with format anomalies), you don't have the foresight needed to write the test before the code.

I think the notion that you (eventually) get to broad code coverage in a full test pass with a single pushbutton test, that Fowler talked about, is the best idea.

I think that whether to use mocks is really dependent on your particular environment, and the penalty of not using them. I've had to mock legacy servers that I couldn't touch in testing, and they helped there a lot. Also ones with really slow IO, or bizarre security requirements that make impersonation in test difficult or impossible.