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.
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:
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With