Ask HN: Should you TDD a MVP?

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.

I think it's ok to go without tests at the start of your project, but at some point you have to transition to using TDD, otherwise the ability to refactor the codebase or change existing features becomes difficult and time-consuming.

To give a rough idea, I spent ~ 2 1/2 months working on my app (Dashku.com) before I wrote a single test for it. Then when a company approached and asked to use it with a special requirement, I realised it needed tests in order to be deemed production-worthy. Now the app has tests (both unit and integration), and I'm now resuming adding features to the product.

I think that this is a wrong question to ask. You have probably so many more important questions to answer while working on your MVP.

If you are accustomed to test driven development then you will know (or at least you will be able to reason about it) when to apply it and when not to. It is just another development practice. But I do not think that you will fail if you do TDD or if you do not. But you do risk failing if you emphasize the wrong things such us should we use X or Y development practice. Use whatever works for you and your team (if you are not alone).

To give you a more concrete answer: follow common sense and your team's suggestions. Avoid making a development practice one of your priorities.

When I'm starting out I find writing a cucumber scenario is a great way to focus on getting a useful feature done. It's the first thing I add to a project. The general setup is done as part of getting that first scenario to pass. After that I do whatever is fastest. I use cucumber scenarios as tracer bullets for new areas of functionality but if I'm refining perhaps I won't bother. As always though, it depends...

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...)