Given that it's an iterative process, I'm referring to subsequent times round the loop.
Without doing detailed up front design of every class in your system, it's likely that you will write a class in one iteration and then change it in a future iteration. Possibly quite drastically.
The biggest problem I've got here is doing this in a compiled language. As soon as you write a new test for an as-yet-unwritten unit, your entire build fails to compile. This can make it unnecessarily difficult to determine what has and hasn't broken by the changes you're making in order to make the new test pass.
If instead you write the Unit Test - and I do only mean Unit Tests here - afterwards then you know that your code all compiles and that all existing tests still pass. You know the interface to your new code. You can test it and make sure it works, and if it fails or if the interface isn't as good as you first thought it's still easy to tweak.
Of course, the single most important thing here is - this is just my opinion. Everyone is different. There is no single perfect way to do this. If writing all of the tests first works for you then do not stop doing that. Do whatever works best for you to create great things :-)
Just curious what language and tools are you using? I have never ran into these issues using TDD. I use Visual Studio and it tells me right away what the compiler errors are. And if I am missing a class or function I just use the refactoring tools to create or rename them at will. Sounds a lot of issues might be tool related.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.