Неявная типизация и TDD

Question

Я только что прочитал эту запись , и это доказывает необходимость использования неявной типизации при запуске с разработкой / дизайном, управляемым тестом.

В его посте говорится, что TDD может быть "замедлен" при использовании неявной типизации для возвращаемого типа при модульном тестировании метода. Кроме того, он, кажется, хочет получить тип возвращаемого значения, указанный в тесте, чтобы стимулировать разработку (что имеет смысл для меня).

Данный модульный тест с неявной типизацией может выглядеть так:

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

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

Итак, мои вопросы:

Помогает ли использование неявной типизации или мешает написанию модульных тестов для TDD? Есть ли кто-нибудь, кто может поделиться своим опытом использования этой техники при написании юнит-тестов?

Я спрашиваю об этом, потому что скоро я не сделал TDD и хочу знать, существует ли способ написания универсальных или полуграничных модульных тестов, которые сработали бы, возвращаемый тип может измениться.

Answer 1

Я понимаю его точку зрения, но я не думаю, что это правильная причина, чтобы не использовать var здесь. Помните, что TDD работает примерно в соответствии со следующим:

1. Написать новый тест.
2. Если тест не может скомпилироваться (и он не должен сработать!), Напишите достаточно кода, пока тест не скомпилируется.
3. Запустите все тесты.
4. Если тест не пройден, напишите достаточно кода, пока все тесты не пройдут.
5. Рефакторинг.

Независимо от того, используем ли мы var, тест не будет скомпилирован в любом случае, потому что тестируемый метод еще не существует !. Как только мы начинаем кодировать NewMethod, его очки довольно спорные.

Скорее, правильная причина не использовать var здесь заключается в том, что код не указывает, какой тип result. Это вопрос мнения, но var здесь хорошо

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

и для анонимных типов, но не здесь

var m = M();

потому что совершенно неясно, не переходя к объявлению M (или используя IntelliSense), что является типом возврата M.

Answer 2

Да и Нет

В настоящее время в Visual Studio TDD представляет собой небольшую боль, особенно при использовании простоты. var означает отсутствие смысла, тогда, когда вы вводите имя типа, который может еще не существовать, он имеет тенденцию автоматически заполнять что-то, что похоже на то, что вы печатаете, часто это имя тестового прибора.

Visual Studio 2010 имеет первый режим потребления , что делает его идеальным и более подходящим для разработки через тестирование. В настоящее время вы обнаружите (в 2008 году и ранее), что вы должны нажать escape , чтобы скрыть intellisense.

Что касается использования var, то это чисто синатический сахар. На мой взгляд, это намного приятнее:

var type = new MyType();

Понятно, что тип переменной имеет тип MyType. var отлично подходит для дженериков и следует принципу СУХОЙ - Не повторяйся .

var type = MethodCall();

var result = ReturnResult();

С другой стороны, это затрудняет чтение кода, независимо от того, используете ли вы TDD или нет. Хорошие юнит-тесты должны проходить и быть легко читаемыми. Если вам нужно подумать или навести указатель мыши на метод, чтобы увидеть тип возвращаемого значения, это признак плохого, трудно читаемого теста.

Answer 3

С точки зрения инструментов, я бы сказал, что лучше избегать вар. Я использую Eclipse и Java, но я знаю, что такие расширения, как CodeRush и Resharper, предлагают многие из функций, которые я обсуждаю здесь. Когда в моем тесте я вызываю метод, который еще не существует, я могу «быстро исправить» его, чтобы создать метод в нужном классе. Тип возвращаемого значения автоматически созданного метода зависит от его контекста; если я ожидаю возвращение String, тип возвращаемого значения метода будет String. Но если это присваивание переменной var (чего нет в Java - но если бы она была), IDE не знала бы достаточно, чтобы сделать тип возвращаемого значения чем-то другим, кроме var (или, возможно, Object).

Не все используют IDE таким образом в TDD, но я нахожу это очень полезным. Чем больше информации я могу дать в своем тесте IDE, тем меньше нужно набирать текст, чтобы пройти тест.