TDD: Does it get in the way of good API design?

TDD is an API design technique. Every time you write a unit test, you are either creating an API for the first time, or using a previously created API. Each one of those tests lets you "feel" how easy or difficult the API is to use. Each new test forces you to consider the API from a new point of view. There can hardly be a better way to design APIs than to exhaustively use them the way TDD forces you to.

Indeed, this is the reason that TDD is considered a design technique rather than a testing technique. When you practice TDD, you do not design your APIs in a vacuum. You design them by using them!

With traditional API design, it's easy to build yourself into a corner: You can end up with an API that has lots of hidden dependencies (like class A needs B needs C needs D and if you change the order in which the classes are initialized, things start to break).

TDD makes sure you that separate pieces stay separate. It also allows you to see your API from a very unusual perspective: As a user/consumer. Your first question is "How do I want to use this?" not "How do I want the API to look like?" The latter can lure you into a hidden trap while the first leads to something which I call "intuitive API": It behaves as expected.

A word of advice: Don't make TDD your religion. It's a tool and some problems can't be solved with some tools. So if TDD doesn't work for you for any reason, then that's OK. Use as much TDD as you like. Don't be fanatic about it. Over the years, you'll find your comfort zone.

If your API is suffering due to internal requirements of your objects, that's what the facade pattern is for. Not all objects need to be public.

A lot of the pain points of TDD are, in fact, signs of pain points in the design. If it's hard to create a class because it requires 18 dependencies to be passed in, the fundamental problem is that the class has too many dependencies and is going to be quite brittle. It also probably does waaaaaay too much. The "TDD pain" in this case is a good thing, as it makes the other issues more obvious.

The point about TDD i sthat we write tests which call the code as we design it. Consequently we should end up with an extremely usable interface. Of course it doesn't entirely happen by chance. We still have to make the right choices.