I know it's good commenting style on HN to avoid quick one-liners, but TDD is one of those topics that we've kicked around forever. Perhaps a one-liner would he

I know it's good commenting style on HN to avoid quick one-liners, but TDD is one of those topics that we've kicked around forever. Perhaps a one-liner would help clarify things. TDD is a coding practice to help the programmer understand that their mental model of the code does not reflect the actual code itself. That's it. There are some follow-ons, of course, like if your mental model is exactly in-line with the code then logical errors are unlikely (although business errors can be quite common!). Another follow-on is that TDD is much more about design than testing. Once you realize that it's a practice or habit that's all about sending information from the code back to the mind of the coder, all of that other stuff sorts itself out. Shameless plug: this has been on my mind quite a bit lately since I blogged last week on the unreasonable effectiveness of testing as a way out of both cognitive and coding anti-patterns: https://danielbmarkham.com/cognition-versus-programming-the-big-two/ https://danielbmarkham.com/cognition-versus-programming-the-...