Update: Looks like they're working on fixing it as we speak.
Update 2: It's now obsolete. Going to the link provides and empty article.
Microsoft publishes it's own version of Guidelines for Test-Driven Development article, and seems to miss the point completely. If you want to learn what TDD really is, do not read that article, as it will confuse and lead you in the wrong direction. Just Google for it and you'll find lots of very good simple explanations, and guidelines for writing unit tests correctly to make them last.
Someone over there at MSDN messed up and didn't do even that. They seem to think that the fact that you can "generate test method stubs automatically from existing code" makes you test-driven. That is wrong on many levels.
"Test Driven" means your tests drive the creation of code. Even empty methods should be written before a test is run or compiled. When there is no existing code you are free to write tests that:
1. call the method to be created the way *you* would want to call it, and not the way you already implemented it
2. written one by one and them implemented to pass instead of writing many many tests only to figure out a problem in the design which renders half of them useless down the line.
3. make you think more about the problem domain instead of "fill in the blanks" sort of thinking
Do Microsoft's tools actually support TDD?
No and yes. The "Quality tools" in VS 2005 indeed provide means to write unit tests, but in no way provide the means to write in a test-driven fashion. The only feature that remotely supports test-driven development is the refactoring support in C# and VB.NET, and especially the "Create method stub" smart-tag which lets you create a method stub from a call to a method which does not exist. That hardly enough, but its a start.
Automatic test generation does allow however creating test stubs for existing code (i.e. "legacy code"), which is *something*. Testing legacy code is even harder, and most definitely you'd want to write tests for legacy code one by one, and most times you won't be able to call any more than a few methods on an existing class, let alone be able to call all the methods on many classes, since they have so many dependencies on other classes its not even funny.
You''ll find that generating many test method stubs is usually the least helpful thing to do in any unit-testing scenario, let alone test-driven development, yet Microsoft toots it as one of the enabling features for TDD in Team System. That's an insult to the reader's intelligence and frankly, annoys me a lot.
I do see good things in VSTS. The fact that it brings Unit Tests to the mainstream tools of .NET developers is huge. Java developers have had this support in their IDEs for years, and now that it's coming to Microsoft, some things will definitely change for the better. but this is just a marketing guy or an intern trying to point a pig with lipstick. Don't sell something it's not. You're embarrassing me and all the other folks who actually try to talk people into doing TDD, and will want to use VSTS to do it.
Where can I read more on this?
I'll point you to two places which talk about this and how MS is making itself look totally clueless when it comes to TDD, which is not the case, since there are some very good people working there which actually know their stuff. The only thing left now is to remove the offending MSDN post, and hope that the Google archives somehow spit it out of their system. no one should even accidentally come across that article.
Scott Bellware(contains lots of references to other bloggers and what they had to say):
"Rather than shape up Visual Studio to be amenable to Test-Driven Development, and in its ignorance of the nature of Test-Driven Development, Microsoft’s marketing people have simply tried to snow job the developer community into swallowing a wholly different definition of Test-Driven Development. And the very text outlining Microsoft’s understanding of Test-Driven Development betrays its almost complete ignorance of why Test-Driven Development is effective and why it is practiced in the way that it is.
So, this is for the folks at MSDN. Listen up… you’ve already embarrassed yourself once, and you’ve embarrassed your insider and MVP communities by association this time as well..
"Microsoft really needs to do a couple of things here. First, they need to yank the offending content from MSDN before any more people notice how stupid they look. Second, some of the more prominent Microsoft agile bloggers need to step up to the plate to explain what they're doing to evangelize within the company so that this sort of thing is less likely to happen again in the future. "