I've given up on trying to convince others of the usefulness of automated unit testing. It works wonders for me in my own projects, but the hassle of trying to police my co-workers just isn't worth it at work.
Love it? Hate it? I don't care anymore. I know what works for me and that's enough.
Unfortunately, in the Rails world at least, the two have been conflated more often than not - the need for testing has been presented as the need for TDD and vice versa. For newcomers, this may well lead to confusion between the two.
I feel the same way.
I suspect that people are having a knee-jerk reaction because it sounds like more (and boring) work. Just like if someone asked you to write comments to every line of code. Hence the argument "sounds good on paper" which seems to always come up. To me, TDD doesn't sound good on paper at all. It just turned out to be more fun (to my surprise) because it is much easier for me to get into flow.
I've given up on trying to convince others of the usefulness of automated unit testing. It works wonders for me in my own projects, but the hassle of trying to police my co-workers just isn't worth it at work.
The problem with this though is when you end up assigned to "their" project, and you curse how un-unit-testable "their" code is. At which point it's "your" code too.
I don't even bother with that struggle you described anymore.
Get assigned ticket for new feature. Write test outlining how it would work with the assumption that the existing code does what it says it does.
If you find - surprise! - the code doesn't do what it says it does, create a ticket and recurse.
Compared with trying to make the tiniest possible change and running into gotcha after gotcha, this is a far more sane and sanitary procedure. It takes longer, but in the end "your" code meets requirements and you can prove it.
Love it? Hate it? I don't care anymore. I know what works for me and that's enough.