Why you should consider testing the code of your MVP
May 3rd, 2020
I have a strong opinion about testing. I think test are a really important part of creating software. People often feel like it's a waste of time, especially for early-stage projects. Time to market is the most important thing alongside with learning from your potential customers. So why bother with testing? Why spend time writing tests?
From my experience, many seems to consider codebases from early projects as drafts and therefore don't test it. The thing is: you are investing time in this project so why not do it well? I'll explain why I think about the benefits of TDD (Test Driven Development) and testing in the early stages of your product development and why you should, as a tech founder or a developer, consider writing tests on your MVP (Minimum Viable Product).
Tests help you go lean and get rid of the unnecessary features
When you do TDD, you write a failing test first. Then you write production code that will pass that test to green. TDD forces you to think of what you need before you code. Then when you code, are free to focus on the implementation. You can focus on the "how" because the "why" has already been addressed!
Filling a Lean Canvas helps you see what the essence of your business is and get rid of the unnecessary stuff so that you can go straight to the next step that will earn you money. Tests help you achieve that as well in a sense.
Let's say you start a product. Your product is called "Orangr". It's a startup that helps you find the perfect orange in your area. You are a developer so you start imagining the perfect platform where orange producers can fill up information about their oranges, upload videos, etc. So next thing you are doing is start coding an admin interface so that moderators can remove fake orange spammers from your marketplace.
Is that the right thing to do right now? That's a problem you don't have yet. Shouldn't you be writing business code that will select the perfect orange for the customer instead?
A test helps you do that. You start with a simple test with a sample orange set and you expect your program to find the perfect orange, given criteria. That's a one-liner so don't tell me it's too long to write:
expect(findThePerfectOrange(sampleOrangesSet)).toEqual(testOrange1)
That's it. That's the core of your domain logic. That's what you should be focusing on in the early stages. It is what makes your business unique. The rest of the code is just wiring stuff together. That's the part you want to spend the least amount of time on. And tests help you keep focused on the important part.
Tests help you focus on the problem rather than the solution
Being a founder (or a developer), you could be tempted to spend more time thinking about the solution than the problem. It's perfectly understandable. The solution is the thing you will sell. The solution is the shiny object everyone loves.
But, you should spend more time thinking about the actual problem and the persons having it (your potential "customer segment" and "problem" columns in the Lean Canvas).
By writing tests, you write down code that explains the problem you are solving.
If you find out that your test makes no sense, then maybe what you intend to do doesn't make sense either.
Not testing: the illusion of velocity
You might feel more productive not writing tests. "I'm good, thanks." I've witnessed what I and other developers do when we are not doing TDD: we write a bunch of code, alt+tab (or go to the other screen) and wait for the refresh to finish so that we can witness the proper result in the browser.
When the app is getting more and more complex, this simple scenario transforms into something like: "I go to the account page, activate this option, then go back to the other page to flip one switch and then move to a third page to check the result." This looks like a lot of time wasted to me.
Instead, you could a small amount of time to just write a test and replay it all in under a second.
A side effect of doing it is that in the future when you'll have thousands of domain cases to check at each release, you'll be able to check them all in a few seconds (or minutes).
Tests will save you time in the long run but more importantly, it will have short term benefits too!
Complexity
I've heard lots of people complain that tests are hard too complex to write. If that's the case, then maybe what you try to achieve is unnecessary complex. If your test has a few hundred lines of setup then that's where your problem is.
Take a step back and think this through. Is it real complexity or accidental complexity that you have got here?
You might have turned something trivial into a monster of complexity. Tests help you figure that out before the damage is done.
An investment for the future
Let's say your app works. You have your first happy customers and they are talking about your product a lot. Congratulation, you achieved a product-market fit! Now what?
You'll have to onboard a few other developers to keep up with the growing demand.
I've had two onboarding experiences with a company that didn't do testing and a company that did. Guess which one went well and which one was garbage? On the company that did testing the rules were simple. When you make a change you write a test. All the test suite must be green before sending it to the production environment.
It makes everyone much more relaxed and helps new recruits be productive faster (without the fear of breaking stuff all the time).
Wrapping up
Testing and TDD have benefits in any codebase. Skipping them gives the illusion of velocity but in the end, you run the risk of deviating from your objective and make your life more difficult. Even in a quick prototyping environment you should take some time to write tests. Good tests must be short and cover your domain logic, what makes your business unique.
Think about it next time you start a new product (and let me know how it worked for you). You will save your time and provide more value and quality to your customers.