Ask HN: Should you TDD a MVP?

The problem boils down to this: TDD makes your software more maintainable (if you do it well) and it lowers your cost of development. However, it also takes significant time and effort to figure out how to test-drive a technology for the first time. Everybody can TDD a Stack class; TDD'ing a database, or a web server, or JavaScript [0] is a lot harder.

So the answer seems simple: use TDD for the parts you already know how to TDD.

But it's not so simple! It's much harder to add tests to existing code than it is to TDD it from scratch. Sometimes, it's flat-out impossible. The expense is so high, there's a very good chance that you'll never get around to adding tests to the un-TDD'd code. It will hang around causing bugs, preventing refactoring, and sapping your agility forever, or until you rewrite... and a rewrite of any significance will halt your company in its tracks, so you won't do that.

So the reality is that, anything you don't TDD from the beginning, you'll probably never be able to TDD. Companies that go down this road find themselves doing a major rewrite several years down the road, and that's crippling [1].

There's another wrinkle on top of this: manually testing code and fixing bugs is expensive. Once your codebase gets above a certain size--about six developer-weeks of effort, let's say--the cost to manually test everything exceeds the cost to TDD it. (The six weeks number is a guess. Some people argue it's less than that.)

So the real answer is a bit more nuanced:

1. If your MVP is truly a throw-away product that will take less than six weeks to build and deploy and you'll never build on it after that, use TDD only where it makes you immediately faster.

2. If your MVP is the basis of a long-lived product, use TDD for the parts you know how to TDD and don't do the parts you don't know how to TDD. Be creative about cutting scope. If you must do something you don't know how to TDD, figure it out and TDD it.

3. It's okay to be a bit sloppy about TDD'ing the edges of your app that are easily rewritten or isolated in modules. But be very careful about the core of your system.

That's my opinion based on 13 years of doing this stuff, including building five successively-less-minimal MVPs over the last nine months for my JS screencast. The first three MVPs were zero coding, the fourth was a throw-away site, and the fifth was TDD'd with aggressive scope cutting to minimize the number of technologies that had to be TDD'd.

[0] Shameless plug: I have a screencast on TDD'ing JavaScript that I'll be opening up to the public, on a subscription basis, in a month or so. http://www.letscodejavascript.com .

[1] Rewrites are crippling: See Joel Spolsky's "Things You Should Never Do, Part I." http://www.joelonsoftware.com/articles/fog0000000069.html (There is no Part II, by the way.)

For a startup, customers are how you pass the test. Anything else is a red light. So in the most important way possible, as long as you have no customers, you have a test which is failing.

This is important because the maintainability you're looking for in a startup is your relationship with the customer. Manage that and the rest takes care of itself. If you are already in a business, yes, "maintainability" means writing code that will last. But if you've just got an idea or a dream, you've got nothing worth maintaining. Nor will you ever.

Put differently, your technical debt can never exceed the economic value of your code, which in a startup is extremely likely to be zero. (Different scenario entirely for project-based work for ongoing businesses, which is why TDD makes so much sense in that scenario)

Does TDD help you? If so, use it! If not, don't! The whole point of an MVP is to ship something ASAP. Do whatever helps you do that.

Personally I've found TDD to be a tremendous waste of time for most things, but I know some people swear by it. It's your product. Git 'er done in whatever way you've learned to get things done.

Edited to add: People talk a lot about TDD leading to more maintainable, less coupled code. There's more than one way to skin a cat—not using TDD doesn't necessarily doom your codebase, and using TDD won't necessarily save it. Like I said, do whatever works for you.

> manually testing code and fixing bugs is expensive

The codebase almost always starts small and simple, and the ratio of cost of development to the cost of testing will look misleadingly acceptable. Here's a made-up ratio:

2:1

As the codebase and complexity increase, keeping those ratios in the same proportion when manually testing is pretty much impossible, and the ratio may actually invert. Again, a made-up number:

1:2

If the business is relying on rolling out new features to continue to grow the business, this could become a big problem if revenue isn't growing at an even faster pace.