Сводный необходимый в методе модульного теста
Включите строку, в основном компилируется в if-else-if лестничную структуру. Попытайтесь декомпилировать простой. В любом случае тестирование строкового равенства должно быть более дешевым, так как они интернируются и все, что было бы необходимо, проверка ссылки. Сделайте то, что имеет смысл с точки зрения пригодности для обслуживания; если Вы - строки compring, сделайте строковый переключатель. Если Вы выбираете на основе типа, лестничная структура типа является более соответствующим.
8 ответов
Я думаю, что длинное описательное имя более важно, чем комментарий XML. Поскольку модульный тест не будет частью API, вам не нужен XML-комментарий.
Например:
[TestMethod]
public void FormatException_Should_Thrown_When_Parse_CountryLine_Containing_InvalidNumber()
{
...
}
более полезен, чем:
///<summary>
/// Exception Should Thrown When Parse CountryLine Containing InvalidNumber
///</summary>
[TestMethod]
public void Test42()
{
...
}
XML-комментарии должны использоваться для документирования API и каркасы.
Лично я стараюсь сделать тесты достаточно простыми для чтения, чтобы документация была излишней. Я использую встроенные комментарии в методе тестирования, чтобы объяснить , почему я делаю что-то определенным образом, а не то, что я делаю.
Не обязательно, но если вы чувствуете, что комментарии XML добавляют ценность сверх имя самого модульного теста (которое выглядит исчерпывающим), тогда вы будете оказывать другим разработчикам услугу.
В приведенном выше примере я бы сказал, что в этом нет необходимости, если только вы не используете инструмент, который извлекает документацию из источника (например, javadoc или что-то в этом роде).
Общее практическое правило состоит в том, что код говорит о том, что вы делаете, а в комментарии говорится, почему, но поскольку имя очень подробное (что, я думаю, нормально, поскольку никто никогда не должен его вводить), я не думаю, что комментарий что-то дает.
Необходимо добавить сводку, если сводка может предоставить дополнительную информацию, которая может / должна быть закодирована в имени метода. Обратите внимание: когда я говорю «необходимо», когда говорю о любой документации, я имею в виду «необходимо передать 100% необходимого контекста / деталей / нюансов новому кодировщику, унаследовавшему проект, или вам самому через 5 лет».
XML-комментарий не нужен, если у вас есть описательное имя метода. И это обязательно для методов модульного тестирования.
Вы уже на правильном пути, имея описательное имя метода тестирования. (Многие практикующие Agile и TDD считают, что метод тестирования должен включать в себя «следует», например, как показано в тексте ссылки в этом сообщении в блоге.
Лично мне нравятся такие названия методов:
MyClass_OnInvalidInput_ShouldThrowFormatException()
Но это просто мои личные предпочтения.
Соображения по платформе
Это зависит от платформы, используемой для вычислений с плавающей запятой. С x87 FPU преобразование осуществляется бесплатно, так как содержимое регистров одинаково - единственная цена, которую вы можете иногда платить, - это трафик памяти, но во многих случаях трафик даже отсутствует, поскольку вы можете просто использовать значение без какого-либо преобразования. x87 - на самом деле странный зверь в этом отношении - на нем трудно правильно различить числа с плавающей запятой и двойные, поскольку используемые инструкции и регистры одинаковы, что отличается от инструкций загрузки / сохранения, а сама точность вычислений контролируется с помощью битов состояния . Использование смешанных вычислений с плавающей запятой и двойными вычислениями может привести к неожиданным результатам (из-за этого есть параметры командной строки компилятора для управления точным поведением и стратегиями оптимизации). лучше использовать свое время, делайте это, иначе не делайте этого. Я бы не стал.
Я действительно предпочитаю использовать DescriptionAttribute вместо сводного тега. Причина в том, что значение атрибута Description будет отображаться в файле результатов. Это упрощает понимание сбоев, когда вы просто просматриваете файл журнала.
[TestMethod,Description("Ensure feature X doesn't regress Y")]
public void TestFeatureX42() {
..
}