The title, ‘It’s Not Bad, Yet. It Will Be: Thoughts on Testing Startup Apps’ is one that was added after the fact. This originally appeared as an answer on a popular Q&A site (see foot note).
Context: A founder asked the following question: ‘Is it bad that I don’t have a single test written for my Startup Web App written in Rails? It’s an online analytic app. I’m not used to writing Tests, but with my Dev team we understand the features that we implement and make sure things are in place before we go into production.
This is not my first time. I have been launching and developing for the last 5 years. But, I just wonder what are some pitfalls of that practice.’
It’s not bad. Clearly you’ve not had an “a-ha” moment with testing yet though. When that time comes, you’ll lament on how terrible it was when you didn’t have unit and functional tests. You’ll likely push a feature to production only to realize 3 days later that the newly released code breaks some obscure part of your system. Upon fixing that, you accidentally push more bugs to production.
Then you hire new engineers. They’re CONSTANTLY submitting pull requests laden with bugs. So you put more stringent code review requirements on them. You don’t trust their code and you end up wasting more and more time fixing the issues they create.
Your new hires eventually learn their way around, and if you were smart while hiring, they even know their way better than you do now. As a matter of fact, one asshole of a developer has now written ~33% of your codebase and he’s decided to leave your dumb startup to work for BetterSalary Co. He followed your lead: no testing whatsoever.
Now you’ve got to implement a new reporting feature that extends functionality written by your old, and more handsomely-paid, subordinate.
“Oh GOD,” you cringe as you open his code. You plead with the coding gods to help your plight, but alas, they do not help you. Coding gods do not exist.
As you trudge and hack your way to completion, you realize that you literally have no idea what’s happening, why your code works, or even how long it will work. “Let’s try this out in staging…” you wisely muse. Nothing works. You ponder the issue and A-HA! “TIMEZONES!” You exclaim. How could you forget to take into account timezones?
You push a fix. Ok, that got you a little further, but it’s still breaking on some of the code that your colleague wrote.
Next week, you’ve got slightly less hair, your co-founders are feeling slightly less confident in your ability and you finally feel vindicated – you just pushed that stupid reporting feature.
In group chat, your sales team is going nuts. “WE CAN’T GET INTO OUR WIZWOG THINGY AND ALL OF OUR OPERATIONS HAVE STOPPED.”
Good thing you at least take snapshots. Le rollback.
If only you had setup tests. You might not have pushed all those bugs to prod and your new hires would have some guard rails while they learn the ropes. Furthermore, given sufficient time, complexity will prevent you from groking all parts of your system. You need to test so you stay productive as time goes on.
So, it’s not bad, yet. It will be.
This article is adapted from an answer to a question titled ‘Is it bad that I don’t have a single test written for my Startup Web App written in Rails? It’s an online analytic app.‘ by John Fawcet.