It has steps for getting going with TDD that state:
1. Define the requirements of your application.
2. Familiarize yourself with the feature areas of your application, and decide on a single feature, or the requirements of a feature, to work on.
3. Make a list of tests that will verify the requirements. A complete list of tests for a particular feature area describes the requirements of that feature area unambiguously and completely.
4. File work items for feature requirements and for the tests that need to be written.
5. In Visual Studio, create a project of the type you want. Visual Studio supplies the initial production code in the form of files such as Class1.cs, Program.cs, and Form1.cs, depending on the project type.
6. Define the interfaces and classes for your feature or requirement. You can add a minimum of code, just enough to compile. Consider using the Class Designer to follow this step. For more information, see Designing Classes and Types.
The traditional TDD process does not contain this step. Instead, it advises that you create tests first. This step is included here so that, while creating tests, you can take advantage of two features in Visual Studio 2005 Team System: the GUI design capabilities of the Class Designer, and the automatic test-generation capabilities of Team Edition for Testers.
7. Generate tests from your interfaces and classes. For more information, see How to: Generate a Unit Test.
8. Compare the tests that have been generated with the list of tests you prepared in step 3. Create any tests that are missing from the list you wrote in step 3. For more information, see How to: Author a Unit Test.
While they do bother to make the note about traditional TDD, they are missing out on several major benefits of TDD:
• TDD is design as you go.
• When you use TDD the interfaces and classes you create emerge as an outcome of writing the tests. This helps to keep the code as simple as possible.
• TDD is about writing one test at a time to DRIVE the DEVELOPMENT of the code. This way the developer does not attempt to predict how the code (interfaces+classes) will look when finished, rather code that passes the tests will be written and refactored as needed.