[1_800_UNICORN]

If you're an early-stage startup that's still determining product-market fit, then it's completely fair to eschew tests and accumulate tech debt; you're at a higher risk of running out of runway before you've even proven that your business works.

As soon as you have enough users that an outage poses a significant risk to your business, you need to invest in either refactoring to reduce tech debt, or a rewrite. And you NEED to add tests, and a robust deployment process that tests changes at multiple stages with monitoring on the basics (server speed and memory usage, database error rate, etc).

OKCupid got lucky in this case.

[holmberd]

Easy to say, but unfortunately rarely seen in the wild, depending on the experience of the project manager. Once that product is live and climbing, no owner wants to hear talks about slowing down for reasons of better test coverage or refactoring.

[usefulcat]

I think the point is more that the slowing down is going to happen anyway if production systems are repeatedly catching on fire and people are afraid to make changes. At that point the difference is how having or not having tests will affect things in the longer term.

[holmberd]

Indeed, but prototypes running in production or running without tests, is a symptom of other underlying problems in the organization. I feel that scope creep and lack of testing goes hand in hand for projects that are poorly managed.

[nradov]

Skipping tests generally doesn't allow for creating a working MVP any faster. It's just an illusion.

[always_good]

Only if you are referring to perfect tests which cost zero time to write/maintain and only the tests written that eventually will catch an issue.

Otherwise, tests have a cost just like any other code. You can see this by looking at both extremes: perfect tests (described above) and useless tests. For example, tests that make your codebase too brittle, tests that don't actually test anything useful, spending too much time writing tests, spending a lot of time writing tests for precisely the code with high disposability, tests that are too coupled with the code, stupid tests that should be removed but won't be because tests tend to be append-only, etc.

Testing is an advanced topic where every +1 unit you spend on testing doesn't mean your application is now +1 unit more robust. +1 unit of time spent in tests can even mean your application is -2 units worse because testing is a trade-off.

So tests are more than capable of hamstringing your unlaunched MVP. They're also capable of being the reason you launched your MVP sooner than later. But the costs of testing are no illusion.

[nradov]

Tests save you time. They have a negative cost.

[leoedin]

Some tests save you time. Some tests don't. It's perfectly possible to write a huge, fragile, heavily coupled test suite which takes days or weeks to modify when you make even a tiny change to the code it's testing.

Just as code falls on a spectrum between clean and completely unmaintainable, so do tests.

[sonofaplum]

Test save you time (maybe) in the long run. But in the search for product market fit, you may conceptualize, design, build, release and then scrap a feature within the course of a month. That's not a long enough lifespan for the tests ROI (better code, fewer bugs, better architecture) to be positive.

[spc476]

The regression test [1] for our legacy application takes five hours to run. It takes five hours to run because it also needs to check every log message (via syslog) to ensure every transaction happened.

I can't say it saves any time, and it certainly does not have a negative cost.

[1] There are no unit tests, as there are no real "units" to test. It's a legacy code base of C and C++, using a proprietary library that no one left in the company has much experience with. Said proprietary library is considered "legacy" by the company that owns it. I've seen the code. No wonder they consider it "legacy" (it started life in the mid-80s and god does it show).