Действительно ли имена модульного теста важны?

[RowTest]
[Row("GoodName")]
[Row("GoodName2")]
public void Should_validate_username()
{
}

[RowTest]
[Row("BadUserName")]
[Row("Bad%!Name")]
public void Should_invalidate_username()
{
}

Это могло бы иметь больше смысла для более составных типов проверки действительно.

Да, они. Я лично рекомендовал бы смотреть правила SSW к лучшим модульным тестам . Это содержит некоторые очень полезные рекомендации по именованию.

Имя должно иметь значение в причине. Я не хочу электронное письмо от сборки, говоря, что тест 389fb2b5-28ad3 перестал работать, но просто зная, что это был тест UserName в противоположность чему-то еще, поможет гарантировать, что правильный человек добирается, чтобы сделать диагноз.

Да.

 [Test]
 public void UsernameValidator_LessThanLengthLimit_ShouldValidate() {}

Помещенный испытуемый сначала, тестовый оператор затем и ожидаемый результат в последний раз.
Тот путь, Вы получаете ясный признак того, что он делает, и можно легко отсортировать по имени :)

Да, имена полностью важны, особенно когда Вы запускаете тесты в консоли или непрерывных серверах интеграции. Поля сойки записали сообщение об этом .

, Кроме того, поставленные хорошие тестовые имена с одно утверждение на тест и Ваш комплект даст Вам большие отчеты, когда тест перестанет работать.

Очень. Одинаково важный как выбирающий хороший метод и имена переменной.
Намного больше, если Ваш набор тестов идет в упомянутый новым devs в будущем.

Что касается Вашего исходного вопроса, определенно Answer1. Ввод еще в нескольких символах является маленькой ценой для оплаты за

• удобочитаемость. Для Вас и других. Это устранит, 'что я думал здесь?' а также 'WTF является этим парнем, достигающим в этом тесте?'
• Быстрое увеличение, когда Вы находитесь в зафиксировать что-то, которое кто-то еще записал
• мгновенное обновление для любого посетителя набора тестов. Если сделано правильно, просто пробегание через названия тестовых сценариев сообщит читателю спецификаций для единицы.

В Чистый Код , страница 124, Robert C. Martin записи:

мораль истории проста: Тестовый код так же важен как производственный код. Это не второразрядный гражданин. Это требует мысли, дизайна и ухода. Это должно быть сохранено столь же чистым как производственный код.

Да, смысл тестового имени - то, что оно говорит Вам, что не работает, когда тест перестал работать.

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

я не поместил бы условия, которые тестируют потребности встретиться на имя, потому что условия могут измениться вовремя. в Вашем примере я рекомендовал бы назвать как

UserNameLengthValidate()

или

UserNameLengthTest()

или что-то подобное для объяснения, что тест делает, но не предположение параметров тестирования/проверки.

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

я называю свой тест с помощью следующего шаблона. Каждое тестовое приспособление пытается сфокусироваться на одном классе и обычно является именем {ClassUnderTest} Тест. Я называю каждый метод тестирования {MemberUnderTest} _ {Утверждение}.

[TestFixture]
public class IndexableFileTest
{
   [Test]
   public void Connect_InitializesReadOnlyProperties()
   {
     // ...
   }

   [Test,ExpectedException(typeof(NotInitializedException))]
   public void IsIndexable_ErrorWhenNotConnected()
   {
     // ...
   }

   [Test]
   public void IsIndexable_True()
   {
     // ...
   }

   [Test]
   public void IsIndexable_False()
   {
     // ...
   }
}

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

Примечание, это только работает, когда модульные тесты очень конкретны и не проверяют слишком много в одном модульном тесте.

Так, например:

[Test]
void TestThatExceptionIsRaisedWhenStringLengthLargerThen100()

[Test]
void TestThatStringLengthOf99IsAccepted()