For me, the biggest point is that unit tests are not a stand-in for understanding your code. It's like that quote about driving by just crashing into the guardr

For me, the biggest point is that unit tests are not a stand-in for understanding your code. It's like that quote about driving by just crashing into the guardrails all the time. Most unit-testing evangelists sound to me like they're using (or even advocating for) unit testing instead of thinking deeply about their code. Slow down and understand your code. If you're finding more mistakes by running unit tests than by thinking through and re-reading your code, you're not finding most of your mistakes. Because you're not understanding your own code. How can you even write great unit tests if you don't understand what you're doing? There are, of course, times when writing the tests first can help you think through a problem -- great! Especially when thinking through how some API would look. But TDD as a methodology gets a hard reject from me. I certainly reject the argument "unit testing is too hard" -- then your code is bad and you should focus on fixing it. Well-written code is automatically easy to unit test, among 60 other benefits. That's not a reason to avoid unit testing.