Sometimes, when I feel like I know the basic domain and can think of something reasonable that I could use as a "north star" test end-point, I work like this. Think anything that could be a unit test, or even a simple functional test. But when I don't know the domain, or if it's some complex system that I have to come up from scratch, writing tests first often makes no sense at all. Then I'd usually start literally drawing on paper, or typing descriptions of what it might do, then just start coding, and the tests come much, much later.

Right tool for the job, as always! The only thing I can't stand is blind zealotry to one way or the other. I've had to work with some real TDD zealots in the past, and long story short, I won't work with people like that again.

TDD comes up with some really novel designs sometimes.

Like, I expect it should look one way but after I'm done with a few TDD cycles I'm at a state that's either hard to get there or unnecessary.

I think this is why some people don't like TDD much, sometimes you have to let go of your ideas, or if you're stuck to them, you need to go back much earlier and try again.

I kind of like this though, makes it kind of like you're following a choose your own adventure book.

I prefer to write an initial implementation, and then in the testing process figure out which interfaces simplify my tests, and then I refactor the implementation to use those interfaces. Generally, this avoids unnecessary abstraction, as the interfaces for testing tend to be the same ones you might need for extensibility.