Sometimes when we catch up in a conversation involving Lean Startup the subject of Tests and TDD get in the way. As always there are haters that say you shouldn’t use TDD (or even write tests) in your tech startup because that’s a waste of time and money. Of course, that sounds reasonable for the novice lean-er guy; if you think Lean Startup is about “don’t build anything your customers don’t want” the idea of tests doesn’t directly drive any value to your customers. Think about it: will your customers have a better experience just because you have really good code quality? No. If you’re building the wrong product, but still it’s well tested and has amazing coverage, will that prevent you to fail? Of course NOT! But testing and TDD on a lean startup is important for other reason.
It’s true that the lean philosophy indicates that the waste must be minimized. Everything that doesn’t drive value to customers should not be built. That’s a fact, and belongs to the Lean methodology (the roots of Lean Startup). But, how do you know what drives value to your customer? Itearting and learning, the cornerstone of lean startup. Lean Startup focuses on “Validated Learning” and uses it as a unit of progress.
As Eric Ries says: “Startups that succeed are those that manage to iterate enough times before running out of resources” Time is crucial. The more iterations you can make, the higher are the chances to find a sustainable business. We can argue then that one objective we can have is to minimize the time we spent on the build-measure-learn loop. If we make that time as small as we can, we’ll be able to cycle around it more times and the chances to run out of resources are lower.
This is where tests (and TDD) comes into scene. Having a solid tests foundation allows you to move fast when experimenting. You can have a hunch (based on a Leading metric, of course ;-) ) that says “we should remove this thing” or “we should separate that form in two parts” that you want to test. But what happens if any time you want to run your experiments the whole website blows up? Your speed through the loop gets downgraded. You’re slowed down, and you’re even jeopardizing the experiment with weird bugs that change the experiment randomly.
That’s why tests and TDD are crucial for a lean startup. Tests allows you to iterate fast and with a high level of self-confort and security through the build-measure-learn loop.
I mention Tests and TDD all the time because you’re not strictly obligated to TDD in order to have a solid tests base in your project. But for me (and this an arguable opinion) it’s the best way to do it. I find it really stressful to go back and look at some piece of code and write the tests in order to make them pass based on the code instead of the opposite (and better for me) way.
Coming from a software development background, we're heavy users of Test Driven Development here, so this post resonated to us when we came across it.