Jeremy Miller at CodeBetter (among many others) has pointed out that Microsoft's newly published guidelines for 'test driven development' are sadly misguided.
Microsoft seems to be trying to redefine TDD to match up with their
tools instead of creating tools that support TDD best practices.
[Via CodeBetter.Com]
Indeed, the guidelines have obviously been written by somebody told to explain how you can use the VSTS unit test generation tool to enable test driven development - a misguided effort as should be obvious from the fact that the tool is called a 'test generation' tool - i.e., it generates tests based on code you've already written. The point of test-driven is to write tests first. What MS is describing here is at best 'stub-driven' development.
What's sad is that VS2005 does have one new feature that really is a godsend for testdriven programming - the 'generate method stub' right-click option. It enables you to write tests for methods that don't even exist yet - truly test driven. Here's how:
You're coding your test for the process of granting a permission to a user. you've already got a User class, but it doesn't yet know anything about permissions. so, you write yourself a quick test:
[TestMethod]
public void GrantPermission()
{
User user = new User();
Assert.IsFalse(user.HasPermission("CanDoStuff");
user.GrantPermission("CanDoStuff");
Assert.IsTrue(user.HasPermission("CanDoStuff");
}
Now, you can't compile this, because your compiler will tell you that User doesn't define a method called HasPermission() or one called GrantPermission(). But you can right-click on those method names and say 'Generate Method Stub', and presto, User now does have those methods (the stub generator will infer the return type and the parameter types for you), and you can compile it. And, in true test-driven fashion, you now have a test which fails (the stubs throw NotImplementedException), so you're allowed to go and write code.
This enables a really liberating style of coding, that really is test-driven - powerful stuff. A shame Microsoft's documentation team didn't spot this as a better way to explain how to do test-driven in VS2005.