Подтвердить что ты не робот

Являются ли имена модульных тестов важными?

Если имена единичных тестов могут устаревать с течением времени, и если вы считаете, что сам тест является самым важным, важно ли выбрать мудрые имена тестов?

ie

[Test]
public void ShouldValidateUserNameIsLessThan100Characters() {}

verse

[Test]
public void UserNameTestValidation1() {}
4b9b3361

ОТВЕТЫ

Ответ 1

Название любого метода должно дать понять, что он делает.

IMO, ваше первое предложение немного длинное, а второе - недостаточно информативное. Также, вероятно, плохая идея поставить "100" в названии, так как это, скорее всего, изменится. Как насчет:

public void validateUserNameLength()

Если тест изменяется, имя должно быть соответствующим образом обновлено.

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

Да.

 [Test]
 public void UsernameValidator_LessThanLengthLimit_ShouldValidate() {}

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

Ответ 5

В Очистить код, стр. 124, Robert C. Martin пишет:

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

Ответ 6

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

Ответ 7

Да, вся суть тестового имени заключается в том, что он сообщает вам, что не работает, когда тест не работает.

Ответ 8

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

UserNameLengthValidate()

или

UserNameLengthTest()

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

Ответ 9

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

Я называю свой тест, используя следующий шаблон. Каждое тестовое устройство пытается сосредоточиться на одном классе и обычно называется {ClassUnderTest} Test. Я называю каждый тестовый метод {UserUnderTest} _ {Assertion}.

[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()
   {
     // ...
   }
}

Ответ 10

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

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

Итак, например:

[Test]
void TestThatExceptionIsRaisedWhenStringLengthLargerThen100()

[Test]
void TestThatStringLengthOf99IsAccepted()

Ответ 11

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

Ответ 12

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

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

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