[faizshah]

I like this quote from Kent Beck:

“ It is impossible to test absolutely everything, without the tests being as complicated and error-prone as the code. It is suicide to test nothing (in this sense of isolated, automatic tests). So, of all the things you can imagine testing, what should you test?

You should test things that might break. If code is so simple that it can't possibly break, and you measure that the code in question doesn't actually break in practice, then you shouldn't write a test for it...

Testing is a bet. The bet pays off when your expectations are violated [when a test that you expect to pass fails, or when a test that you expect to fail passes]... So, if you could, you would only write those tests that pay off. Since you can't know which tests would pay off (if you did, then you would already know and you wouldn't be learning anything), you write tests that might pay off. As you test, you reflect on which kinds of tests tend to pay off and which don't, and you write more of the ones that do pay off, and fewer of the ones that don't.”

Source: https://softwareengineering.stackexchange.com/a/244709

[josephg]

When I’ve gone full TDD on projects, I’m always surprised to find there’s a power law distribution or something on failing tests. Most of the tests I write never catch a bug in the life of the software. Something like 90% of the value of a test suite could be achieved with only about 10% of the tests. Of course, the trick is figuring out which tests are going to repeatedly fail ahead of time. But there’s something interesting down this rabbit hole.

I wonder if it would be worth collecting per-test stats through the life of a project to explore this.

[lmm]

You'd get a lot of the value by just being willing to delete tests once it's clear they're not serving any purpose. Sadly a lot of people would rather see a high test coverage percentage than have an effective test suite.

[nitrogen]

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

[lmm]

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.

[ornornor]

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.

[lmm]

> 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.