In the MS world, they have you creating a list of tests you think you'll need, then using VisualStudio to generate your code, then using VisualStudio to generate tests. Then you compare the tests to the list, and add any that are missing.

Michael Feathers has a few issues with that:

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.

...

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.

What it sounds like to me is this: The VS team tried to warp TDD so that it hit the strengths (as they see them) of their tools. I wouldn't call what they came up with TDD though.