A few weeks back while listening to .NET Rocks Episode 408, I cringed so badly when I started hearing Dr. James Whittaker, who is, apparently, in charge of Visual Studio Team System's testing tools (which I surmise includes the oft-admonished MS Unit Testing framework), talk about test driven development and his gripes about it.
Right then and there I saw it: Microsoft's attitude about test driven development has been totally wrong, precisely because they were asking the worst possible person about it. Whittaker is the worst person to talk about test driven development, because he's focused on testing.
Microsoft failed to understand, outright, that test driven development is NOT about testing.
Scott Bellware responded to Whittaker's statements via the Hanselminutes podcast, wherein he offered The Last Word On Test Driven Development on Episode 164. There, he questions (at around 5:30 into the podcast) "why test-driven development is coming out of a conversation about software quality and software quality tools":
I think it's quite sad though that no matter [how much we tell people] that TDD is about design rather than testing, that it never really sank in...
Questions about software quality are damaged when we let them fall over into conversations about test driven development...
The goal with [TDD] isn't really a unit testing goal although we're borrowing unit testing tools to achieve the goal... [We're almost like] "demonically" possessing unit testing to achieve other needs.
["The Last Word on TDD" on Hanselminutes]
I said as much when someone asked on Stack Overflow whether TDD takes focus away from design. In my response, I stated that it's precisely the opposite -- that, once again, TDD is all about software design:
If done right, Test Driven Development IS your design tool.
[...]
Test Driven Development, done right, should make developers highly aware of design pitfalls like tight coupling, violations of DRY (don't repeat yourself), violations of SRP (Single Responsibility Principle), etc.
If you write passing code for your tests for the sake of passing your tests, you have already failed: you should treat hard to write tests as signposts that make you ask: why is this done this way? Why can't I test this code without depending on some other code? Why can't I reuse this code? Why is this code breaking when used by itself? ["Does TDD take away focus from design?" on Stack Overflow]
The reason why I don't take this misconception lightly is because this realization came to me the hard way -- I was part of a project wherein Test Driven Development was grossly misunderstood by previous members of the project:
There was... a failure to recognize that TDD is not about tests, it's about design. The rampant case of singleton abuse in the unit tests made this obvious: instead of the test writers thinking "WTF are these singleton = value; statements doing in my tests?", the test writers just propagated the singleton into the tests. 330 times.
The unfortunate consequence is that the build server-enforced testing was made to pass, whatever it took["When TDD goes red" on Dotnet @ Kape ni LaTtEX]
The attitude Microsoft took regarding this issue explains a lot why testing is an add-on "luxury" feature to Visual Studio, which you pay extra for, and not part of its core features out-of-the-box, and on top of that made it definitely illegal to implement in Visual Studio Express. Hiring a testing expert to implement a software design engineering guide lead to the inevitable misrepresentation of the value of TDD.
Unfortunately, treating TDD as a luxury feature gives the impression to hobby and professional software developers alike that test driven design is nothing but a bell and a whistle in Visual Studio -- which it is not. Test driven development is a paradigm in software development, and to many it has become a fundamental way of ensuring that code for software of any size and complexity is flexible and maintainable and remains that way.
So repeat after me: TDD is about design. It's NOT about unit tests. Tell that to the every developer who asks what TDD is all about, and to every developer who thinks TDD is about testing.
