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

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

17 голосов
/ 19 мая 2010

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

Ответы [ 8 ]

8 голосов
/ 19 мая 2010

Предполагается, что 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);
}
5 голосов
/ 19 мая 2010

Я просто пишу для чего. Это не значит, что вам придется вводить имена где-либо еще, поэтому наличие testWibbleDoesNotThrowAnExceptionIfPassedAFrobulator не проблема. Все, что является тестом, очевидно, начинается с «теста».

2 голосов
/ 19 мая 2010

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

Лично я фанат следующего - пример кода на C #, но очень близко к 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 , это обеспечит легкость чтения и выполнения ваших тестов.

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

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

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

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

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

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

2 голосов
/ 19 мая 2010

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

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

1 голос
/ 19 мая 2010

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

  • GetTest - это положительный тест (все в порядке).
  • GetTestInvalidIndex для проверки неверного индекса, передаваемого методу.
  • GetTestNotInitialized для проверки, когда данные не инициализируются перед использованием.
  • SetTest
  • SetTestInvalidIndex
  • SetTestTooLargeValue
  • SetTestTooLongString
1 голос
/ 19 мая 2010

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

1 голос
/ 19 мая 2010
0 голосов
/ 19 мая 2010

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

...