TDD and Visual Studio Team System

A co-worker brought this post by Scott Bellware to my attention on the guidelines Microsoft has on MSDN for test-driven development and how these don't really conform to traditional TDD approaches.

Scott makes some excellent points the most important of which IMHO are:

TDD helps you design the code by writing the test first and then making the code conform through refactoring of the interfaces etc.

TDD tests don’t necessarily map one to one with methods in a class

This point about test generation in the tool came up at a developer event on Team System I attended last July in Redmond. I got the impression that the MSFT folks fully understood the concerns of the agile community (they were loudly voiced in much the same way Scott articulated in the blog) but that since not everyone was or is doing agile, having the autogeneration feature was still valuable. I agree that the guidelines miss the mark but that said there is a disclaimer in the document that they’re not following "traditional TDD".

I could see an organization using a mix of both approaches based on the type of development you're doing. When designing a class library from scratch for use by other developers I might following the "traditional" route so that I'm not constrained in my design by my first thoughts, but when another developer uses my library and inherits from it they might like to autogenerate some unit tests. They are more constrained and so using the autogeneration might be more productive for them.

We have this situation with the Service Agent Framework we built. I haven't spent that much time in VS2005 to know how I would use the Class Designer in the former approach but my guess is that as I refactor to conform the design to the test I’ll do most of that work in the Class Designer.