Taking Automated Tests Off The Pedestal
plus.google.com
plus.google.com
Tests themselves are a form of code coupling so they almost always come with a cost.
I do agree with you (and said as much in my comment on G+) that there is some danger to this discussion becoming and excuse for laziness and ignorance, but that in itself isn't a good reason to not have the discussion.
Certainly I've broken tests with new code, examined broken tests, and simply nuked the broken tests before. Usually it's because they're either better covered by some other test written since then, or covering use cases I thought I'd have that never emerged. Sometimes I fix them to be less brittle over time.
It is a good discussion in theory, I just question whether there's that many teams for which this really applies.
I may be suffering from excessive reliance on my own personal experience. As I said yesterday in another comment, I tend to not to worry about whether something is "unit" or "integration" or "acceptance" testing, and most of testing is actually at least one abstraction level above what would be properly considered "unit testing". I personally don't have much difficulty with test stability as a result. People who write lower level unit tests may encounter this far more often.
Finally we've started to move beyond that. But unfortunately we've ended up more or less lurching into a general mindset of unfettered adulation for testing. On balance that's probably better than the unwashed heathenism of earlier but it's still a dangerous situation to be in. Automated tests have their own pitfalls. Test code is often lower quality than regular code, for example, requiring special care to keep it up to par. Also, it's all too easy to write passing tests which hinder rather than enhance your ability to modify the code base (which, by the way, is the primary reason to have automated tests in the first place).
The proper way to approach testing is openly and directly, by having an honest debate on the level of testing necessary, the cost of testing, and the processes necessary to ensure that tests are high quality and providing value. Sometimes this can result in a decision to not test some aspects of a product. And that's ok as long as that decision is made rationally.
More so, as Fowler says, automated testing is just one tool for increasing the quality of a product, but in many ways it is not the most effective one. Formal code reviews and beta testing, for example, have shown to be some of the most effective techniques for finding defects. Additionally, they are capable of finding defects that testing cannot: defects at the level of design.