Live data from Hacker News

All of us test in production all the time (2019)

increment.com

161–164 of 164 posts

Re: All of us test in production all the time (2019)

#161
post #159

Earlier quoted context omitted.

What is the value of deleting a test once it's written, though?

Tests impose a maintenance burden like any other lines of code. Just making it harder to navigate to relevant code (including useful tests) is a significant cost.

You’ve already paid the cost for writing the test, might as well keep it.

If a test fails when modifying the codebase or adding a feature or updating dependencies, it still serves a purpose in my opinion even if fixing it takes some time.

Having the test no matter how trivial also helps boost confidence that a new change didn’t break anything no matter how trivial.

But tests should be refactored once in a while, and if a thing is complicated to setup for testing, either the thing to test should be refactored before shipping and/or the developer working on that thing should also ship a factory and helper functions for testing that thing.

Re: All of us test in production all the time (2019)

#162
post #159

Earlier quoted context omitted.

Tests impose a maintenance burden like any other lines of code. Just making it harder to navigate to relevant code (including useful tests) is a significant cost.

You’ve already paid the cost for writing the test, might as well keep it. If a test fails when modifying the codebase or adding a feature or updating dependencies, it still serves a purpose in my opinion even if fixing it takes some time. Having the test no matter how trivial also helps boost confidence that a new change didn’t break anything no matter how trivial. But tests should be refactored once in a while, and…

> If a test fails when modifying the codebase or adding a feature or updating dependencies, it still serves a purpose in my opinion even if fixing it takes some time.

> Having the test no matter how trivial also helps boost confidence that a new change didn’t break anything no matter how trivial.

If it catches an error in your change, that's a benefit. If it delays a correct change with false positives, that's a cost. (And if a passing test "boosts confidence" but the change is actually broken, that's another, more subtle cost). Often the cost is larger than the benefit.

> But tests should be refactored once in a while, and if a thing is complicated to setup for testing, either the thing to test should be refactored before shipping and/or the developer working on that thing should also ship a factory and helper functions for testing that thing.

That's all valid assuming the tests are providing some value. But just like with any code, the first question should be whether it's serving a useful purpose at all - if not, then deleting is cheaper and more effective than any amount of careful refactoring.

Re: All of us test in production all the time (2019)

#164

Earlier quoted context omitted.

The author originated the meme. It is not meant to be interpreted as sarcastic.

So much the worse.

On the contrary, it's the best strategy for reducing risk in modern web service architectures.
Post reply on HN