To be fair, it seems that everyone other than I took this in the context of more traditional software project, not an ill-specified one man startup project.
ok, so now I get it. TTD is better suited for those large companies where people don't know what the f are doing, so they need to test everything (just making sure), and when speed doesn't matter, as big companies everything goes slow.
The same enviroment and thinking that brought us java, and made it a clusterfuck of "abstractions", and "design principles".
I'd rather just code ad design at will, and be able to refactor, change, or throw away code without being held hostage of these tests which will break at some point, not because your code is not right, but because they were design to test something according to a thinking, and when that something changes, all those tests are obsolete.
I think the problem that you might be facing is more related to the quality of your tests than testing itself. If your tests are written correctly, you should never have to throw them away when you refactor.
In fact, that's one of the major benefits of testing: a refactoring safety net!
Right. How can you refactor code that has no tests? Basically, you've got no clue if your new refactored code works because all the precious time you've spent using the old code went towards ephemeral tests that weren't written down. That makes refactoring a lot more risky than it needs to be.
I was referring to the later.