Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The most obvious missing one:

   (c) You start wasting a lot of time fixing the features you previously shipped but broke later.
When you start to waste so much time manually testing stuff, and realizing that something you implemented and worked two weeks ago, but now doesn't because someone forgot to check that their new work didn't break the old one.


Why are you keeping around features that aren't tied to revenue? Either write tests for the features, or delete the features. The easiest code to test and maintain is no code at all.


Okay? Some products take more than just a few lines of codes and a few days to build. Absolutist opinions aren't useful.

Also, just about everything can be construed as being tied to revenue. Not a useful heuristic.


Honestly, in most cases testing is a band-aid on top of a bigger problem. IME things usually break due to complexity, not due to lack of tests.

But of course, tackling complexity is hard. It's much easier to sprinkle the big ball of mud with tests and set it in stone.

If you feel like you're wasting time manually testing, it probably means that the blast radius of your changes is too big. You should prefer smaller rockets over your head, not bigger bunkers to hide in.


Some stuff just takes time to manual test, e.g. if you provision multiple cloud resources and must coordinate them. Or anything involving some sort of multi step process. If you want to ship quickly, you want a test suite to save you the trouble of doing an hour long of manual test for each change you're adding. Delegating the verification to computer, so that my small team can move faster on the other things we need to build, is a no-brainer. At least, once the "cost to manually test" becomes greater than "cost to implement some tests and setup CI".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: