I would argue that the more pernicious result is tests that are correct and do pass at the moment they were written but are brittle, test internal interfaces an

I would argue that the more pernicious result is tests that are correct and do pass at the moment they were written but are brittle, test internal interfaces and data, and generally ossify the design of the project because making any change now involves making the change and fixing the dozen tests the change breaks. It's hard to say no to those tests, because, on the surface they appear very thorough, and look brilliant on objective metrics, like branch/function coverage tools. It's only later, when every change, no matter how trivial, requires at least five or six files to be touched, that you come to realize the tarpit that you've ensnared yourself in.