I don't see unit tests "catch bugs" often, either, in the sense that the CI build fails due to defective code pushed up.
And even with TDD, I don't often find myself breaking a lot of things that were already working, though it does happen. In those infrequent cases, it's extremely valuable to know I broke stuff that was working. I.e., it's pretty sad to ship changes that broke other behaviors, things you had the faintest clue that you were impacting.
What I do see gobs of, when doing TDD, is the tests preventing crap code from getting integrated in the first place, i.e. when I or others first write the code (or change the code of others). From the testing perspective, that's the real thing they do--gate the defects from ever leaving your desktop, and in a far faster manner than most other routes.
Unless, of course, one is a perfect coder.
In any case, TDD has more important benefits that I've also gotten. Easily worth it for me.
Sure, still, 20 years on. Not dogmatically so to reach some coverage goal, but anything with real logic, yes. I don't test-drive React components, for example (instead the goal is to get all real logic out of them).
Benefits--not pushing logic defects gives me more time to invest in other important stuff; I end up with tests that document all the intended behaviors of the stuff I'm working on (saves gobs of time otherwise blown trying to understand what code does so I can change it safely); I'm able to give a lot of attention to ensuring the design stays clean. Plus, it's enjoyable most of the time.
"They incur technical debt and bugs at the same rate as other code." Not at all true.
And even with TDD, I don't often find myself breaking a lot of things that were already working, though it does happen. In those infrequent cases, it's extremely valuable to know I broke stuff that was working. I.e., it's pretty sad to ship changes that broke other behaviors, things you had the faintest clue that you were impacting.
What I do see gobs of, when doing TDD, is the tests preventing crap code from getting integrated in the first place, i.e. when I or others first write the code (or change the code of others). From the testing perspective, that's the real thing they do--gate the defects from ever leaving your desktop, and in a far faster manner than most other routes.
Unless, of course, one is a perfect coder.
In any case, TDD has more important benefits that I've also gotten. Easily worth it for me.