Ask HN: For a startup, when should I begin writing tests?

Hello!

We're building our MVP and have got commitments from our first few customers. I'm still young and haven't managed production software before, only personal projects.

I'm hesitant to sacrifice developer velocity for tests. I believe product agility is a huge asset early on, and I think testing cuts into this.

I'm also afraid of digging an inescapable hole of untestable spaghetti code and tech debt.

I'd love to hear the thoughts of more experienced engineers and founders on this issue! How did you balance it, and what would you have done differently? When should I start testing?

My current idea is to skip testing, and instead put that effort into product development and a robust deployment pipeline with easy roll-backs. Ideally this would allow us to move quickly and revert any big mistakes, without the burden of a complex test suite.

If it's important, we're React+Go, but I'm not looking for stack-specific advice.

I can speak to this. I wrote the vast majority of code for two years for a startup. The stack, if it matters, was ruby on rails with jQuery.

I would write tests from the get go. I would have to look at the got history to be sure, but I believe I started adding to the test suite after about a month of adding code (I did use an existing open source project as the base of the product, and they had a lot of tests written). Your fears about spaghetti code are valid and tests will help with that. At the least you can refactor with less fear, though with golang that will be less of an issue than it was with ruby. In addition they will help prevent regressions. When I (or, far more likely, our users) found a bug in the system, I would write a test before fixing it. Therefore, we had very few bugs return.

However, a deployment pipeline is critical too, because otherwise your tests won't get run often enough (especially if they are slow. Due to the way I wrote the tests, and the number of them, it took approximately 20 minutes to run through all the tests in our ci environment).

Re: your fears of slowing things down. In my experience a test suite, even a bad one, will speed things up once you are in production. This is because it will prevent regressions and doing manual testing, both of which chew up additional time. I saw this at other companies.

Start writing test as soon as you start losing time due to regression bugs. But don't ignore the first signals :).

Once you get experience in having a TDD approach, my view is that you don't lose time with testing. Writing tests is a way to formulate your thought and assumptions. You implement this in your code and you selectively run these using the tests. You reduce the size of the code that you think about to small building blocks. This makes you much faster-writing code. The amount of rework getting components to work together is reduced allowing you to implement features faster.

Only if your code is complex, will you need a complex test suite. If your code is complex you won't be fast implementing features anyways. TDD will help you keep your code simple.

I would try to make adding tests as easy as possible. That is for every piece of code you write think to yourself: How would I test this. If in many cases the code only makes sense in the context of the whole application running this might be a sign of danger. Basically you thinking testing might slow you down is a sign this might be the case. For some problems it is way easier to write tests than to solve them correctly.