Лучшая практика для методов именования и методов тестирования интеграции?

Недавно я унаследовал приложение, написанное разными людьми в разное время и ищущее руководство по стандартизации.

Ответы

Ответ 1

Предполагая NUnit:

[Test]
public void ObjectUnderTest_StateChanged_Consequence()
{
    Assert.That(tra_la_la);
}

[Test]
public void ObjectUnderTest_Behaviour_Consequence()
{
    Assert.That(tra_la_la);
}

например:

[Test]
public void WifeIsTired_TakeWifeToDinner_WifeIsGrateful()
{
    Assert.That(tra_la_la);
}

[Test]
public void WifeIsTired_MentionNewGirlfriend_WifeGetsHalf()
{
    Assert.That(tra_la_la);
}

Ответ 2

Я просто пишу, для чего это. Не похоже, что вам придется вводить имена в другом месте, поэтому наличие testWibbleDoesNotThrowAnExceptionIfPassedAFrobulator не является проблемой. Все, что является испытанием, начинается с "теста", очевидно.

Ответ 3

Поучительно посмотреть на BDD (поведенческая разработка) и в этом сообщении в блоге в частности.

BDD в основном фокусируется на компонентах и ​​что они должны делать. Следовательно, это напрямую влияет на то, как вы называете/структурируете свои тесты и код, который они используют для настройки условий и проверки. BDD позволяет не только разработчикам читать/писать тесты, но и нетехнические члены команды (бизнес-аналитики и т.д.) Могут вносить вклад, задавая тесты и проверяя их.

Ответ 4

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

Лично я поклонник следующего примера кода на С#, но очень близко к Java, применяются те же правила:

[Test]
public void person_should_say_hello()
{
     // Arrange
     var person = new Person();
     // Act
     string result = person.SayHello();
     // Assert
     Assert(..., "The person did not say hello correctly!");
}

Явное

Имя теста должно содержать имя тестируемого класса. В этом примере тестируемый класс Person. Имя теста должно также иметь имя метода, который тестируется. Таким образом, если тест был неудачным, вы, по крайней мере, знаете, где искать решение. Я также рекомендовал бы следовать правилу AAA - Arrange, Act, Assert, это гарантирует, что ваши тесты будут легко читаться и следовать.

Дружественные сообщения об ошибках

Когда дело доходит до утверждения результата/состояния, полезно включить необязательное сообщение. Это облегчает выполнение теста, особенно когда выполняется как часть процесса сборки или с помощью внешнего инструмента.

Подчеркивает

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

Интеграционные тесты

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

Ответ 6

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

Ответ 7

Я использую конструкцию FunctionTestCondition. Если у меня есть два метода: Get и Set, я мог бы создать следующие методы тестирования:

  • GetTest является положительным тестом (все в порядке).
  • GetTestInvalidIndex, чтобы проверить недопустимый индекс, передаваемый методу.
  • GetTestNotInitialized, чтобы проверить, когда данные не были использованы перед использованием.
  • SetTest
  • SetTestInvalidIndex
  • SetTestTooLargeValue
  • SetTestTooLongString

Ответ 8

Группируйте свои тесты по настройке, создайте тестовый класс вокруг этой настройки, а имя - с помощью теста суффикса или IntegrationTest. Использование тестовой структуры, например JUnit или TestNG вы можете назвать свои методы тестирования по своему усмотрению. Я бы назвал метод как то, что он тестирует, предложение в случае с верблюдом, а не тестовый префикс. Структуры используют аннотацию @Test для обозначения метода как теста.