Well, here's the link:

Now, let's talk about it.

The crux of Test Driven Development is that you use tests to drive the creation of your code, and in that loose sense, the guidelines pass muster, but there's more to it than that, really.

The key advantage that TDD gives you is feedback. You write a failing test case, make it pass, and then you formulate the next test case. The wonderful thing is that when you get to that next test case, you have the feedback from getting the first one to pass to draw upon. Often that feedback will lead you to formulate the next test case in a different way. It could even lead you to produce a different interface for the class you were writing.

Now, what I've described might sound bad. It might sound like, well, maybe the decisions that you make during development will drift a bit. Drifting might not sound very good but the fact is it is good in this case. It's good because we control it. We are able to incorporate the things that we learn immediately when we learn them. The alternative is to ignore things that we learn or not learn them at all, and that's not a very clever strategy.

The style of TDD described in the guidelines would have us jump ahead and write five, ten, maybe twenty test cases before getting the first one to pass. You can do that, but it's like putting on a set of blinders. When you don't have to formulate the next test case right after passing the last one, there isn't much chance to think about improvements. Worse, there is a disincentive to thinking about them: if you find any, you have to delete all of the speculation you've hardcoded in the tests and interfaces you created in advance.

Just for the record, I'm not a Microsoft-basher. I've met quite a few people who work there and they are very smart, people I have a lot of respect for, but there is something mysterious that happens in nearly all large organizations. Ideas get passed from person to person through a grapevine, and the form that they end up in is rarely the form they start in. It's a lot like politics, really. Politicians can't send nuanced messages because they know that only the most simplified version of what they say will propagate, and they have to be very careful that the simplified version of what they say isn't counter to their intentions. But, that's probably a topic for another blog.

Right now, I hope that MS revisits their guidelines. Yes, they have a tool that generates test stubs, but using it for TDD looks counter-productive. Adding stubs to legacy code? That would be great, but getting in the way of the feedback cycle? Bad. Bad. Bad.

    IntegerStack stack = new IntegerStack();
    int value = 5;
    stack.Push(value);
    Assert.AreEqual(5, stack.Pop());

    class IntegerStack
    {
        public void Push(int value)
        {
            throw new NotImplementedException();
        }
        public int Pop()
        {
            throw new NotImplementedException();
        }
    }