> If I were to implement some feature by writing a test for it first, I'd have to have a very clear idea of exactly how the feature should behave. I'd need to have chosen a suitable name for it, worked out what parameters it should take, and what it should return. And when I came to write the function in question, I'd find that most of the hard work had been done up front, and the tough design decisions taken already, leaving me only the task of writing some relatively trivial code to make the test pass.

One difficulty I have with this is that, while defining everything upfront like this works nicely in well-understood domains (such as implementing pre-established business logic), elsewhere my understanding of the problem only really forms through writing code and seeing what approaches work.

Normally I try to keep code minimal and easy to change to start with so I can quickly refactor, and then stabilize with proper tests/documentation/interfaces/extensibility as other things start relying on it. Maybe this should be a separate prototype phase, which I throw away before starting the proper TDD production version? But I'm not sure if it's usually cleanly demarcated enough for that.

> Of course, this assumes that the code works right now, but why wouldn't you assume that?

I feel TDD has to some extent the same problem in the opposite direction: you're writing code to pass the test, so the test becomes less useful at finding potential errors and logic issues with the tests may be copied over to the code.