Implicit typing and TDD

Question

I just read this post and it makes the case against implicit typing using when starting out with Test driven development/design.

His post says that TDD can be "slowed down" when using implicit typing for the return type when unit testing a method. Also, he seems to want the return type specified by the test in order to drive development (which makes sense to me).

A given unit test with implicit typing might look like this:

public void Test_SomeMethod()
{
    MyClass myClass = new MyClass();

    var result = myClass.MethodUnderTest();
    Assert.AreEqual(someCondition, result);
}

So my questions are:

Does using implicit typing help or hinder writing unit tests for TDD? Is there anyone out there that can share their experience using this technique when writing unit tests?

I ask this because soon I have not done TDD and want to know if there is a way to write generic or semi-generic unit tests that would work a return type might change.

Answer 1

I see his point but I don't really think it's the right reason to not use var here. Remember, TDD works roughly according to the following:

1. Write a new test.
2. If test fails to compile (and it should fail!), write enough code until the test compiles.
3. Run all tests.
4. If a test fails, write enough code until all tests pass.
5. Refactor.

Whether or not we use var the test will fail to compile either way because the method under test won't exist yet!. Once we start coding up NewMethod his points are rather moot.

Rather, the right reason to not use var here is because the code gives no indication what the type of result is. This is a matter of opinion but var is okay here

var dict = new Dictionary<Foo, List<Bar>>();

and for anonymous types but not here

var m = M();

because it's completely unclear without going to the declaration of M (or using IntelliSense) what the return type of M is.

Answer 2

Yes and No

In Visual Studio presently, TDD is a bit of a pain, especially when using implicity typing. var means no intellisense, then when you enter the name of a type that may not exist yet it has the tendency to auto-complete with something that is similiar to what you are typing, often the name of the test fixture.

Visual Studio 2010 has a consume first mode, which makes it ideal and better for Test Driven Development. Currently you'll find (in 2008 and earlier) you have to hit escape to hide intellisense.

As for use of var it's purely synatic sugar. It makes the following much nicer in my opinion:

var type = new MyType();

Its clear that the variable type, is of type MyType. var is great for generics and follows the prinicple of DRY - Don't Repeat Yourself.

var type = MethodCall();

var result = ReturnResult();

On the other hand, this makes for hard to read code, whether you follow TDD or not. Good unit tests should flow and be easy to read. If you have to think, or hover the mouse over a method to see the return type, that is the sign of a bad, hard to read test.

Answer 3

From a tooling perspective, I'd say it's nicer to avoid the var. I use Eclipse and Java, but I know that extensions like CodeRush and Resharper offer many of the features that I'm discussing here. When in my test I call a method that doesn't exist yet, I can "quick fix" it to create the method in the desired class. The return type of the automatically created method depends on its context; if I am expecting back a String, the return type of the method will be String. But if the assignment is to a var (which Java doesn't have - but if it did), the IDE wouldn't know enough to make the return type anything other than var (or maybe Object).

Not everyone uses the IDE in this way in TDD, but I find it very helpful. The more information I can give the IDE in my test, the less typing I have to do to make the test pass.