Implicit typing and TDD
c#, implicit-typing, tdd, unit-testing
Solution
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:
- Write a new test.
- If test fails to compile (and it should fail!), write enough code until the test compiles.
- Run all tests.
- If a test fails, write enough code until all tests pass.
- 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.
Problem
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.