But you should know this from your functional requirements, right?
(Slightly sarcastic comment, I know in a lot of places people just start coding without a plan, but I think TDD and functional requirements go together well).
Well, I don't do that. But i usually don't know all the names of my (internal) interfaces and models and properties right at the start. I might move things around and rename stuff along the way. And I think that's quite normal if you don't live in a world where the spec for a small task is multiple books thick.
Doesn't TDD get in the way with? Wouldn't I keep refactoring the tests all the time then?
Functional requirements describe observable behaviour. You can't write any meaningful tests for that behaviour until a lot of your code is written.
Yet somehow in all the discussions there's this unexplaned leap from "you have the requirements" -> "well you just write a unit test for your function first, and then code it".
My functional requirements come in the form of "Given publisher A in Country B and contract requirements C the service must return D for a subset of products E", for multiple combinations of A, B, C, D, and E. And where each of those may and will require lookups in external services and databases.