[mbrock]

The reason is that if you can write a test that specifies your unit in terms of its communication with collaborators, then you have achieved a rational and comprehensible unit of code, and so you can be more sure that your design is sound.

With test-driven design (in an ideal world), if a change to an important module can break its own tests only, that means that it has a shallow and clear interface, decoupling its internals from the rest of the application.

Given that the module's code is exhaustively tested, that means there is a full specification of what it's supposed to do, given the various possible scenarios.

If the tests are well-written, that means the specification is comprehensible, which means the interfaces make sense in the domain's discourse.

Good TDD involves working hard to keep the code base clean and comprehensible. If you're only testing that everything works together, there's a chance that you're also less focused on maintaining good architecture.