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.