Неявная типизация и TDD
Я просто читал это сообщение, и оно излагает доводы против использования неявной типизации когда начинающийся с Разработкой через тестирование / дизайн.
В его сообщении говорится, что TDD может быть "замедлен" при использовании неявной типизации для типа возврата когда поблочное тестирование метод. Кроме того, он, кажется, хочет тип возврата, указанный тестом для управления разработкой (который имеет смысл мне).
Данный модульный тест с неявной типизацией мог бы быть похожим на это:
public void Test_SomeMethod()
{
MyClass myClass = new MyClass();
var result = myClass.MethodUnderTest();
Assert.AreEqual(someCondition, result);
}
Таким образом, мои вопросы:
Использование неявной типизации помогает или препятствует модульным тестам записи на TDD? Есть ли кто-либо там, который может обменяться их опытом с помощью этой техники при записи модульных тестов?
Я спрашиваю это, потому что скоро я не сделал TDD и хочу знать, существует ли способ записать универсальные или полууниверсальные модульные тесты, которые работали бы, тип возврата мог бы измениться.
3 ответа
Я вижу его точку, но я на самом деле не думаю, что это правильная причина не использовать VAR здесь. Помните, что TDD работает примерно в соответствии со следующим:
- Написать новый тест.
- Если тест не сказывается с компиляцией (и он не должен потерпеть неудачу!), Напишите достаточно кода до тех пор, пока тестовые компилития.
- Запустите все тесты.
- Если тест терпит неудачу, напишите достаточно код до тех пор, пока не пройдет все тесты.
- рефакторист.
Используем ли мы или нет var . Тест не сможет скомпилировать в любом случае, потому что метод в соответствии с тестом пока не будет!. Как только мы начнем кодировать NewMethod , его очки скорее спорные.
Скорее, правильная причина не использовать VAR вот поскольку код не дает никаких признаков, какой тип результат . Это вопрос мнения, но VAR здесь в порядке в порядке
var dict = new Dictionary<Foo, List<Bar>>();
и для анонимных типов, но не здесь
var m = M();
, потому что он полностью неясен, не собирается доклада m (или использование Intellisense) Какой обратный тип м .
Да и нет
в визуальной студии в настоящее время TDD - это немного боли, особенно при использовании текста. var означает отсутствие IntelliSense, затем, когда вы вводите имя типа, который, возможно, не существует, но он имеет тенденцию к автоматической комплектации с чем-то, что и похоже на то, что вы печатаете, часто имя теста приспособление.
Visual Studio 2010 имеет , потребляющий первый режим , что делает его идеальным и лучше для разработки для тестирования. В настоящее время вы найдете (в 2008 году и ранее), вы должны ударить Escape , чтобы скрыть Intellisense.
Что касается использования var , это чисто синатический сахар. На мой взгляд, это делает следующие гораздо приятнее:
var type = new MyType();
Это ясно, что тип переменного, имеет тип MyType. var отлично подходит для джежевов и следует на принципной сухой - Не повторяйте себя .
var type = MethodCall();
var result = ReturnResult();
С другой стороны, это делает жесткий, чтобы прочитать код, будь вы будете следовать TDD или нет. Хорошие модульные тесты должны течь и быть легко прочитаны. Если вам нужно подумать или наведите курсор мыши над способом, чтобы увидеть тип возврата, то есть признак плохого, трудно прочитать тест.
С точки зрения оснастки, я бы сказал, что лучше избегать var. Я использую Eclipse и Java, но я знаю, что такие расширения, как CodeRush и Resharper, предлагают многие из тех возможностей, которые я здесь обсуждаю. Когда в тесте я вызываю метод, которого еще не существует, я могу "быстро исправить" его, чтобы создать метод в нужном классе. Тип возврата автоматически созданного метода зависит от его контекста, если я ожидаю обратно String, то возвращаемым типом метода будет String. Но если присваивание происходит по var (которого у Java нет - но если есть), то IDE не будет знать достаточно, чтобы сделать тип возвращаемого метода чем-то отличным от var (или, может быть, Object).
Не все используют IDE таким образом в TDD, но я нахожу это очень полезным. Чем больше информации я могу дать IDE в моем тесте, тем меньше нужно вводить, чтобы тест прошел.