[crdoconnor]

I find that automated tests shine pretty much all of the time, provided they're relatively cheap to build, cheap to maintain and not buggy.

Where they fall down is when they're more expensive to build than the code under test and they produce false positives/negatives.

[YZF]

I agree. The problem is that almost inevitably they end up getting more and more expensive to build and maintain while at the same time becoming buggy ;) It's a difficult battle to win.

I think you need self discipline to keep limiting yourself to an ever evolving subset that is the optimal ROI. This means over time removing tests that don't add as much value any more. Rewriting some other tests. etc. Human nature though is that these keep growing endlessly and become hard to manage just like any other part of software.

[spronkey]

Hmm, I think this arises from a mindset that doesn't treat tests as part of the code that should be maintained and refactored.

You always have to be removing and refactoring tests if you are changing your production code. Changed a sorting algorithm? Good, go and have a look at your tests to see whether there's anything that doesn't need to be tested anymore, or edge cases that need to be tested now that the algorithm has changed.

Red -> Green -> Refactor

[marcosdumay]

Unit tests tend to get more expensive with time (but not always do). Other kinds of test behave differently.