Making TDD easier
Chris Garty asks what tools are availble to help Test-First development. He says:
“it would be great if my development tool could automatically create empty implementations of the classes and methods I am testing though simple 'right-click to implement unknown class/method/property' functionality. ”
This is something we've thought about before for Visual Studio. I'm going to describe our assessment of this kind of feature, and I want to hear if you think we're on track or not.
1. Intellisense interferes with this style of coding. Suppose you’re in this situation:
class C
{
[TestFixture]
class Tests
{
[Test] void ATest()
{
C c = new C();
c. // about to write a method call here
}
}
}
You’re writing an app to manipulate Everquest, so you want an EQ property on the class. You’re hoping to write c.EQ and want the tool to generate a stub for C.EQ for you.
But when you hit the DOT, a completion list pops up. You ignore it and keep going. When you hit space, semicolon, or whatever, the editor completes to c.Equals for you. This will get annoying pretty quickly.
The behavior I’ve described is wonderful when you misspell a member name, or just type the prefix & want the editor to finish up for you. But in a pure unit-test-first scenario, it’s not what you want at all. (By “pure” I mean you write the call before you write the method).
If you do this a lot, you could go to Tools.Options.TextEditor.C# and turn off Auto List Members, but I’d hate to give up that feature in other cases.
I find myself writing method stubs first. Then I get to use Parameter Help when I write the call.
I suspect you’re in the habit of hitting ESC when the completion list appears & you’re typing a new name.
2. This is most important for methods.
Methods have signatures, so there’s more opportunity for a tool to help you out.
Generating a property in this way isn’t a very big win. Especially when:
a) The prop and propg expansions are available to insert one quickly
b) A public readonly field has the semantics I’m usually looking for, in 1/6th as much code.
c) The Encapsulate Field Refactoring is available, too.
d) Property signatures are so simple.
Generating a class is even less valuable. Classes have only a name. You don’t generate classes nearly as often as you generate methods. We also don’t have good ways to guess where the class should live.
3. Even though getting the signature 100% right isn’t always possible, the feature is still nice to have.
Just generating with the correct number of parameters, all of type object, and named p1, p2, p3, … is the most important. Discerning the parameter types, return type, and names is gravy.
4. This is a productivity feature.
It helps you go faster, but it doesn’t help you do things you couldn’t do before. Compare to, say, Reorder Method Parameters Refactoring, which you probably wouldn’t do without a tool, since fixing every reference is so tedious.
Does that sound about right?
We definitely want to support folks doing Refactoring & TDD, and this feature is part of that story. I’m sure this feature will make it into Visual Studio at some point, but I can say when.