If there is one thing that bothers me most about good terminology in computer programming, it is that if they are *too* good they become mere marketing buzz words. Key example: refactoring. I hear EVERYONE use this now even when it has nothing to do with what they are talking about. There are developers I know (thank goodness I don't work with any of them at Fios) where anytime they go in to legacy code to make a change, they refer to it as "refactoring" the code. Kuso! It just bugs the beejeebeez out of me.
Anyways, in that same vein, imagine my "surprise" (insert incredible amount of sarcasm and disdain here) when I found this post by Jim Shore in which he points to a MS guide on doing TDD with Team System. The problem? What they are describing, while having elements *similar* to TDD, is *NOT* TDD. I wouldn't usually mind this. But come on, call a spade a spade. If it's not TDD, don't use the term TDD simply because it's a "buzz word" of the day.
The more scarier possibility is that the author of the article (whoever it was) actually that it *was* TDD. There has been a lot of research and writings produced on the topic of TDD. How can it be so wrong?
Rather than me trying to add value to this whole debate (which I have none), I confer to the wisdom of some of the greats in this arena.
Uncle Bob's Response (aka Robert C Martin)
Have at it!!