TDD isn't software design, it's design *feedback

Tests drive design in two ways, and I rarely seem them distinguished (including here):

1) By making you think about the interface up front. E.g. if you are designing a REST API writing a test that calls that API that does not yet exist. This almost always a good thing.

2) By making it painfully difficult to write a test - e.g. because you need to mock all over the place. The most annoying thing about this form of feedback is that it does help so it's not completely useless, but it's very expensive and usually has a low if not negative ROI.

I don't find that thought pieces on "test driven design" ever seem to distinguish the two different modes, and they're usually awfully vague about whether they're talking about high level tests matching business logic or low level tests on implementation details because they have very different payoffs.

High level TDD where the tests match the behavior and business logic will often NOT provide design feedback on lower levels. I think this is actually a good thing. It simply provides a safety net to experiment with your designs.