| I'm the founder of https://circleci.com, so I feel I have a little perspective here from talked to dozens of startups about this very question. You should test a different amount based on your goals. TDD does not deliver value to your customer directly, so the only way its even usable in an MVP is helping you iterate and deliver the MVP faster. A common mistake, and it feels like you're doing it here, is to think that TDD is a best practice that you have to do, rather than thinking about how to apply it to improve your productivity. So how will testing help in an MVP? It allows you verify that you haven't broken anything when you write new code, and when you rewrite existing code. But because you'll constantly throw out code, spending a long time doing this will literally be wasted as you throw out the code you're testing. Avoid writing the sort of massive extensive tests that many associate with TDD. When you unit test a function, test or two cases at most, any more that that is overkill. If it takes you 2 minutes to write a function, a function + tests should take at most an extra 30 seconds. If you can't think how to test it, don't. So some specific advice: - when you write a function, you're likely to test it somehow manually (refreshing the browser, at the REPL, etc). Take that manual test and put it into the test framework. It should take 10 seconds more. If it is more effort than this, don't bother. - write MVP-type tests: "what's the minimum I can write here to viably test this"? 1-2 test cases, at most. A positive test and a negative test ideally. And then you're done, move on. - avoid full-browser tests. Those things are a massive time sink, and nothing will change more than your front-end. - use a CI service (self-plug: https://circleci.com). This means you don't have to run tests before you push. Just push and let the server catch it. |