thats kind of TDDs core point. you don't really know upfront, so you write tests to validate what you can define up front, and through that, you should find you

thats kind of TDDs core point. you don't really know upfront, so you write tests to validate what you can define up front, and through that, you should find you discover other things that were not accounted for, and the cycle continues, until you have a working system that satisfies the requirements. Then all those tests serve as a basic form of documentation & reasonable validation of the software so when further modifications are desired, you don't break what you already know to be reasonably valid. Therefore, TDD's secret sauce is in concretely forcing developers to think through requirements, mental models etc. and quantify them in some way. When you hit a block, you need to ask yourself whats missing, then figure out, and continue onward, making adjustments along the way. This is quite malleable to unknown unknowns etc. I think the problem is most people just aren't chunking down the steps of creating a solution enough. I'd argue that the core way of approaching TDD fights most human behavioral traits. It forces a sort of abstract level of reasoning about something that lets you break things down into reasonable chunks.