In "Mock Roles, Not Objects" [1], Freeman, Pryce, Mackinnon, and Walnes say:
A core principle of Lean Development is that value should be pulled into existence from demand, rather than pushed from implementation: The effect of ‘pull’ is that production is not based on forecast; commitment is delayed until demand is present to indicate what the customer really wants.
This is the flow of programming with Mock Objects. By testing an object in isolation, the programmer is forced to consider an object’s interactions with its collaborators in the abstract, possibly before those collaborators exist. TDD with Mock Objects guides interface design by the services that an object requires, not just those it provides. This process results in a system of narrow interfaces each of which defines a role in an interaction between objects, rather than wide interfaces that describe all the features provided by a class. We call this approach Need-Driven Development.
I recently experienced the opposite of this approach. I had done some initial design, and come up with a list of classes and their responsibilities. I picked the most important class and started implementing it.
So how did I mess up?
You need to start at the edge of the system, from the external interfaces and work your way in. My "important class" was not nearly as important as I thought it was, and certainly was not more or less important than any of my other business objects.
When I finally got around to implementing my external interface, which was a messaging layer, I found that some of my earlier assumptions did not hold true. I had over-implemented some of the business objects. It is easy to fall into this trap with TDD, because you can implement your objects before anyone actually needs them.
If I were to do it over again, I would not forgo that initial design, because it certainly helped the process along, but I would always start my implementation with the classes that are closest to the business requirements.
[1] http://joe.truemesh.com/MockRoles.pdf
