How big are your privates?
There has recently been, and will continue to be, increased noise about Team System and its assorted components. The most widely discussed seems to be the unit testing piece, which is encouraging on one level because it means people are interested in unit testing. I have yet to see anyone ask the question "why?", however, as we already have several perfectly good testing frameworks (one of which VSTS blatently clones), with perfectly good (better than VSTS, even) integration with Visual Studio.
Lacking, also, is much contrarian opinion on the "Create Tests" feature in VSTS. I'll state my bias up-front - I think it's a Bad Thing - but I think if Microsoft are going to offer the feature, they should also provide guidance on how they think it should be used. I have several objections to this feature. First, it assumes that there is a one-to-one mapping between methods and tests (even down to the semi-configurable test-name generation). Second, it promotes a test-last culture. Third, it makes it super-easy to test private methods.
I'll expand on those points in reverse. Whether to test private methods is not one of those issues which has an easy, widely-accepted answer, but there are other significant questions which Microsoft should address before jumping off the fence:
* Is unit-testing about testing features or implementation?
* Should every piece of code within a class be testable via its public interface?
* Does coupling your tests to private implementation hinder or facilitate refactoring?
* Does the implementation of the xxxAccessor objects hinder or facilitate refactoring?
* Are private methods a code smell?
* Do framework developers have different API concerns to closed-audience developers?
I think providing an easy way to test private methods solves the wrong problem. Before reaching for the reflection, ask yourself why you can't test that method via the public methods which use it, and consider changing your class-under-test to be more easily testable.
The second point I consider the most important. Visual Studio (even 2005) already offers very little to the test driven developer, and I see "Create Tests" as a backward step. How about a "Create Code" feature instead? Whidbey offers "Generate Method Stub". Would it kill them to add Generate Class, Interface, Field, Local? And the expansions don't count - go and look at IntelliJ, or Eclipse, or even ReSharper. By making it so hard to drive development from your unit tests, it's no wonder that some developers view TDD, and programming by intention in general, with suspicion. Much easier to hack away inside a class and add tests later, that way the "flow" isn't interrupted with the constant flipping between unit tests, code-under-test, and the Solution Explorer. I was at a developer lab for VSTS recently and, I'm not kidding, the presenter offered Generate Method Stub as Visual Studio's support for TDD. He even dedicated a slide to it. I work with guys who would have laughed out loud at that.
Finally, the idea that each method on a class only needs one test method (one called 'SomeMethodTest' at that) should seem weird to any unit-tester, even those not doing TDD. What are you meant to do with the generated test methods? Put all your assertions about each method in one test? Add more tests as you go, thus instantly screwing up the naming conventions? What about tests which involve more than one method on the same class? What if you want to name your test methods after the behaviour they test, rather than the methods they exercise?
It just hasn't been thought through. If it had, they might have realised that providing lower level features to support code generation from the editor would have provided a far more flexible, and less dangerous, solution.