I sometimes hear people object to writing unit tests on the basis that most test failures are false negatives, and that the problems typically turn out to be in the tests rather than the system under test.
I think this largely comes down to how the tests are written, but there is some truth in the objection. Brittle tests are a pain, and if a test is not well written then it can cause friction for developers making future changes.
From time to time, I like to remind myself of the times that unit tests I've written have caught bugs or saved me from my own mistakes early on before others use the code, either in a test environment or in production.
I recently did some work to change how files were saved by the application. Thanks to my unit tests, I caught multiple bugs. I don't remember all of them, but here are three:
During development, I hardcoded a file extension temporarily. In the end, I forgot to go back and replace this with code to get the correct file extension. My unit tests covered multiple scenarios, including different file types, so my mistake became obvious.
I did some string manipulation and got one character too many from a substring. My tests made this very clear and I was able to fix the bug promptly.
When I was ready to merge my code into the team development branch, my tests picked up on the fact that someone else had introduced a bug into the code I was working on. Because I ran my unit tests after merging the code, I immediately found and fixed the problem.
In addition to finding these bugs, my tests also gave me the confidence to refactor. I did change the implementation of my work partway through because we realised the functionality should be hidden behind a feature switch. Having written a suite of unit tests increased my confidence to make changes, and reassured me that my updated code would still work.