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.

I was referring to the later.

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.

What I meant to say is "How can you effectively refactor code that has no tests?"

Refactoring is inevitable. I find that on projects where I've written tests, refactoring goes a lot better.

By refactor he means to change the purpose of the code, not just the implementation. Your tests will not cover this.

Does he? Then he's using the wrong word. Refactoring is changing the implementation while keeping the interface and semantics.

Which, I agree, is one of the shortcomings of unit testing: placing an additional burden on improving interfaces and semantics.