Broadly speaking, there are two approaches to TDD (Test-Driven Development), sometimes referred as the Chicago school and the London school, that differ strongly in their use of mocks. The Chicago school a.k.a. "Classic TDD" builds up from the bottom, working from the inside to the outside, and doesn't need mocks (because you've already built the real objects). The London school a.k.a. "Mockist TDD" builds down from the top, working from the outside to the inside, and relies heavily on mocks for objects-yet-to-created. This blog post from Georgina McFadyen of 8th Light
is a good overview (a lot more material can be found online).
BDD (Behavior-Driven Development
) expands on the London school of TDD in some ways, focusing on expected behavior at a higher level, and using different terminology in order to move your thinking away from "tests" to "specifications". Some people feel BDD is harder for beginners to learn than TDD (but I don't agree), and because it's an outside-in approach, some texts will lean heavily on mocking for BDD. I prefer to follow the BDD approach overall but rely very little on mocking (perhaps I feel less need for mocks since I work primarily in a functional language -- Clojure -- rather than an object-oriented language?). Since I believe you can work effectively in a top-down, outside-in manner without mocking, I tend to encourage BDD/TDD beginners to avoid mocks if possible -- partly because of the issues that Pete is running into here (and if you're doing TDD, actually writing your tests first, and you use mocking techniques, then you will tend not to write final or anonymous classes because mocking works against that... which is another reason to avoid mocking!).