[biesnecker]

No, if your MVP is a total throwaway that you're using solely to validate a hypothesis, and once/if it's validated you'll be redoing everything.

Yes otherwise.

My experience with TDD is that the cost/benefit curve doesn't really pay off until you need to refactor or significantly expand a project, at which point having good test coverage saves you an enormous amount of time/pain.

[rhizome31]

My experience is that doing TDD doesn't take more time, even for initial development. It doesn't take less time either. It's subjective and I haven't done any measurement (I suppose it would be really hard to measure the effect of TDD, all other things being equal, since writing the same software twice using both methods would obviously be misleading).

I do have one clue that TDD takes the same time as non-TDD for me : I used to work as a freelance developer, paid by the hour, for clients to whom I didn't feel necessary to tell whether I would do TDD or not when negotiating the number of hours a given project or task would take. Then I was doing TDD and was still able to deliver on budget. Some of those clients were themselves developers who presumably would know how much time a task should take. The fact that I was doing TDD, or even writing tests at all wasn't part of the discussion about the amount of time it should take. Doing TDD didn't seem to have any effect on my ability to meet the schedule.

I think the reason it works like this for me is that I tend to do a lot more manual testing when I don't write tests (and if I don't write tests first, I tend to not write them at all because the motivation is much lower, the code is already "working" after all...)