> Tests do have a maintenance cost Agreed, but... > Sometimes they rely on interfaces other than the one being tested, and that code needs to be updated when

> Tests do have a maintenance cost Agreed, but... > Sometimes they rely on interfaces other than the one being tested, and that code needs to be updated when those interfaces updated. Generally speaking, an interface will have 2x the consumers in a well tested codebase, which means 2x the refactoring. Only when refactoring the public interface, and only when tooling isn't capable of automating the refactoring. In other words, only when you're doing something complex enough that there's a high chance you'll break things and cause tests to fail! Hopefully one will catch said test failures before checking in - note that this will skew any CI metrics. Just because they didn't fail on your CI infrastructure within the past year, doesn't mean they didn't fail within the past year. > Tests take time to run, which slows the development loop. This is, perhaps, a good reason to make those tests run e.g. only for your overnight integration tests. But removal? Nervously auditing and reviewing changes (both your own, and other's in code reviews) for possible breaks because of reduced confidence that your unit testing will catch things also slows down the development loop. As does the debugging sessions when that isn't enough. > Test can be used as documentation. The more tests in a specification, the less useful that spec is as documentation. This is, perhaps, a good reason to relegate less informative tests to another directory. Perhaps the same directory that houses regression tests that your fuzzer found. > When refactoring, the number of tests increases the amount of behavior that needs to be pulled along. If the test is no longer important to the business, that slows down refactoring unnecessarily. The purist might cry that refactoring doesn't change (external) behavior. But I'll note that it's just as easy to delete unit tests when you're changing behavior, as it is to delete them ahead of time. Even easier! Bonus: Deferring their deletion until then makes the fact that you're actually changing behavior a lot more obvious and explicit. Ahh, a fibbed a little: It might be harder to get those deletions approved by your code reviewer if it's not obvious that changing behavior is OK. In my work environments, this is a feature.