To test or not to test (Startup Perspective)

Ahhhh testing in software engineering. It is not uncommon to hear developers skip writing test, or proclaim their annoyance with it at least. But if that’s the case, why do we still write tests?

Importance of tests

Before we proceed further, we need to first understand the importance of writing tests.

TL;DR:

• Correctness: code does what it says it does (and don’t do what it shouldn’t)
• Easier to add new features: Make changes without worrying about the application breaking
• Know which part of the code is causing the bug
• Give other developers (or future you) a better idea of what the code was intended to do
• And the list goes on…

But almost always, speed is more important

As Facebook founder Mark Zuckerberg once famously said “Move fast and break things”. How I look at it is, we could spend time writing tests to make sure it’s 99% bug-free, or we could spend the same time launching a couple of new features. This is because startups have limited resources like time and money.

Sure, things might break sometimes, but for a startup, moving fast is almost always more rewarding than being right. According to this article on The Top 20 Reasons Startups Fail by CB Insights, 9/10 startups fail due to no product-market fit, running out of cash or getting outcompeted. Most of these scenarios seem to stem from a lack of speed and agility.

Why bother writing tests then

Most people probably don’t know about this, but in 2014, Facebook’s new motto has been changed to ‘Move fast with stable infrastructure’.

As the product grows, at some point, not writing tests slow down the development process. You heard me right. This could be due to reasons like time remedying a catastrophic impact of a bad piece of code (yup, we’ve been there), or simply not having enough confidence to change the code without knowing if it is working or worrying if it breaks another part of the application.

As Mark Zuckerberg nicely explained

… as the company has grown to such mammoth proportions that spending time fixing bugs was slowing it down faster than its risky attitude toward development.

So when do we write tests?

Since startups have limited resources but tests are also important at the same time, when should a startup write tests? Here at NodeFlair, we mostly follow these 2 rules to decide if we should write a test, and it turns out to be working pretty well (so far).

Too many cases to test manually

NodeFlair Salaries is one of the many products by NodeFlair, a Tech Career SuperApp. It allows tech talents to look up the latest salaries in the market. One of its features is to crawl job listings and tag them according to important attributes like specialisations and seniorities.

For example, here’s a screenshot of Salaries for Grab’s Senior Software Engineer, which can be found on NodeFlair Salaries.

To determine the seniority of a job listing, we have a module that requires several arguments such as the job title and years of experience required. We ensure the correctness of the module by running it against a large list of different job titles and checking if the result is correct. Should we make any changes to the way we are deriving the seniority, we don’t want to manually test it against a hundred job title. In this situation, it makes sense to write unit tests, as we can run it against any changes, and therefore, can develop faster.

Potentially catastrophic code

Some code is more “dangerous” than the others. In general, any GET operation will probably be safer than an UPDATE, which is likely to be safer than a DELETE operation. You don’t want a situation where you accidentally wipe out your production database

Forget about the Space-Time complexity. I use the Fuck-My-Life complexity to gauge, which include 2 simple questions:

• How badly can this piece of code fucks up my day
• How tough is it to recover from the worst-case scenario

Conclusion

Here’s a disclaimer: What works for us might not work for you. For example, if you are a fintech startup, there’s probably less room for errors, so more stringent testings will be required. Do adapt as you see fit.

And also, I don’t know how to end off this post… So all the best and I hope all your test suites pass.