No, I appreciate the feedback. I can assure you that yes, I do entirely understand what TDD is (have for at least half my career), and while the two are inexorably related (ergo TEST-driven), you're correct that they're not the exact same thing.
(Yet, perhaps most annoyingly, many TDD-advocates I've read/spoken to over the years blur the line between testing and TDD, as if you have to use TDD to do testing.)
TDD is all about planning, designing, and then with tests as one of your main tools to that end, and that approach simply has never worked for me. I've tried it.
It's also form of functionality-based design, which had already come to be considered inferior to model-based design back when the most exciting part of Robert Martin's weekday was still "recess". (Although there are still situations where functionality-based design has its place.)
Again, as I said, that doesn't mean TDD doesn't work, or that it shouldn't be used. If TDD works for you, use it. But it isn't a magic bullet. It does not fit every situation or every project, no matter how perfectly you implement it. (And, in fact, there are no magic bullets.)
P.S. That's not my article. Like I said, I merely detailed my own testing habits in a comment there.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.