I respectfully dissent. CPAN, for instance, wouldn't be CPAN without “all those tests.” After all, we don't need to be dealing with somebody else's bugs:   we have plenty enough of our own.

Perhaps we can take the viewpoint of Thomas Edison's quote:  “I know a hundred ways to build a light bulb that don't work.” In our case, “we know a hundred ways and places that the code doesn't fail.” This does not, of course, mean that the software is defect-free, because obviously we know that it does have plenty of defects lurking in there somewhere. So the tests that we do have, give us a good foundation for helping to consider where the defects are much less likely to be.

I would also offer the opinion that this becomes a lot more important when you have a large number of developers working on the same project:   there is no longer a single person who “lives, breathes, and sleeps-with this piece of code every day,” who therefore has a gut-instinct about it. More than just a few people now need to have a basis for determining that the code is (and remains) reliable. When a bug happens, all of them have to dig for it, and having some objective sense of where not to start digging (first) is very helpful.