Sometimes one might even think so (actually today for some moments I did). The story: one of our factories "left out" a property, meaning that we simply forgot it, both in tests and codebase. Do I hear someone say "then what are tests for? they are useless as they didn't trap your error"? well the someone I'm thinking about is on holiday so I'll be spared that, but she would be right on one thing: the test, these unit tests at least, did not trap MY error (assuming I wrote that part of the code).
So what? this oversight, when corrected (test first of course), caused some tests related to distant classes to fail, not because the correction was not right, but because the freshly failing tests needed to be updated.
Foolishly, I didn't run the complete suite of tests for the project before committing, so my CI server wrote me that I broke the build. This happened twice.
I must confess it was anoying: I had to add more code to correct the wrong assumptions of the test. This conceptually disturbed me, as I didn't have to fix the code (which was already correct) but the tests (it just so happened it was because I was using a mocking library and I had to set another couple of expectations).
This pushed me to a couple of considerations.
First, it is true that sometimes mocking libraries introduce a dependency you could happily live without.
Second, I would have avoided to trigger a remote build if I ran the whole suite of tests. The problem is that it would have take too long compared (in my opinion) to the small changes I made. Once more, I slammed my face on the wall, so I think I'll play ball by always applying the "Run Private Builds" pattern, that in the end would have saved me time.