"TDD [...] assumes you know what shape your functions and classes and data structures will take before you start coding". Absolutely not. In a green field proje

"TDD [...] assumes you know what shape your functions and classes and data structures will take before you start coding". Absolutely not. In a green field project you might start TDD with an 'architecture' consisting of only one function. Since one single function is a very bad architecture for anything except something extremely simple at some point refactoring would take that function into multiple functions, or make a class of it or do yet something else. The main difference with the CASE approach is that TDD does not presume that we can know an adequate architecture beforehand but instead can figure that out while we are going. I.e., decide things when we actually have the information to do it. TDD actually is the only method of software development that I know of that respects the complexities involved in software development. One might write test afterwards but as I note above tests do cost time so one should aim for the maximum payback of that time. When you start with the test it starts paying back as soon as possible starting from the point where it flags your first attempt making the test pass as not quite working. One case where it may be better to start with some trial and error is when it is not clear what algorithm should be used.