In response to the MSDN Test-Driven Development Guidelines, Scott Bellware has an interesting rant over here.

Update: before I could post this entry, the MSDN posting had been removed, luckily I saved a copy elsewhere. Since I’ve just spent the last few minutes writing this, I’m posting it anyway. Here’s what’s there now:

Guidelines for Test-Driven Development
This topic is obsolete and has been removed from the MSDN documentation.

It would appear that the MSDN posting has hit a nerve in the TDD community, and on first impressions, rightly so. I’m about to embark on a couple of days travel, I’ll be taking some of the material surrounding this posting and rant with me to read, expect to see me follow it up later this month.

To pick on a few posting (on the off chance you’re not following this rant elsewhere): Scott Dockendorf steps up and denounces any involvement in the article over here. Agile guru Roy Osherove is very vocal about the article in his Microsoft fails miserably to explain or promote Test Driven Development in Team System posting. And Julian M Bucknall is all depressed about it over here.

On a separate note, and it’s perhaps why I associated this posting with my “Opinion” category (not that this counts for much, but I feel as if that category lets me write what I like and not get sued! That’ll be right!), as an MVP should I be seen to be criticising Microsoft? Ignoring the relationship that exists, if an organisation did something that was wrong (in the eyes of the majority), I would feel professionally obliged to point out the error in their ways. Even after nearly a decade in the same organisation where such an attitude is pretty much frowned upon, I still maintain this professional desire to see things done properly. However, again on first impressions, I see that the MSDN posting is rapidly becoming MSTDD, so at least the differentiation is there. Hopefully all the TDD newbies will catch up on TDD postings prior to embarking on what amounts to a shoe-horned flavour of TDD.

More when I return from my travels.

Here’s the original MSDN posting:

Visual Studio Team System
Guidelines for Test-Driven Development
If your software-development project uses test-driven development, or TDD, you can benefit from features of Visual Studio 2005, and in particular, features of Visual Studio 2005 Team System. These features include the unit test type of Team Edition for Testers, and especially the ability to generate unit tests automatically; automatic refactoring capabilities that are introduced in Visual Studio 2005, and the Class Designer tool.

The unit test support of Team Edition for Testers is particularly suited to TDD because these Team System testing tools can generate tests from a minimum of production code.

Process Example
In your TDD project, you might want to follow these steps:

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.

Note
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.
9. Organize your tests into test lists. You can, for example, base your lists on test use, such as check-in tests, BVTs, and tests for a full-test pass; or on area, such as UI tests, business-logic tests, and data-tier tests. For more information, see How to: Organize Tests into Test Lists.
10. Update the generated tests to make sure they exercise the code in ways that cover the requirements that you have defined.
11. Run your tests. For more information, see How to: Run Selected Tests.

    Verify that all your tests fail. If any test produces a result of Inconclusive, it means that you did not update the generated code to add the appropriate verification logic for that test. If any test produces a result of Passed, it means that you did not implement the test correctly; this is because you have not implemented your production code, so no tests should pass.

12. Implement the interfaces and classes of your production code.
13. Run your tests again. If a test still fails, update your production code to respond. Repeat until all the tests pass.
14. Pick the next feature or requirement to work on and repeat these steps.