Лучшая практика для именования методов модульного и интеграционного теста?
Я недавно наследовал приложение, которое записано различными людьми в разное время и поиском руководства о том, как стандартизировать.
8 ответов
Предполагая 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);
}
Я наткнулся на два хороших предложения. Ссылки здесь: http://slott-softwarearchitect.blogspot.com/2009/10/unit-test-naming.html
http://weblogs.asp.net/rosherove/archive/2005/04/ 03 / TestNamingStandards.aspx
В этой ситуации я бы, вероятно, нашел наиболее часто используемое соглашение об именах и реорганизуйте остальную часть кода, чтобы использовать это. Если бы тот, который использовался чаще всего, действительно ужасен, я бы все равно посмотрел на существующий код и попытался бы найти тот, с которым я мог бы жить. Последовательность важнее произвольных условностей.
Как такового стандарта нет, разные люди / места будут иметь разные схемы. Важно то, что вы придерживаетесь стандарта.
Лично мне нравится следующий пример кода на 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!");
}
Explicit
Имя теста должно указывать на имя тестируемого класса. В этом примере тестируемый класс - Person . В имени теста также должно быть имя тестируемого метода. Таким образом, если тест не удался, вы, по крайней мере, будете знать, где его решить. Я также рекомендую следовать правилу AAA - Arrange, Act, Assert , оно обеспечит легкость чтения и выполнения ваших тестов.
Дружественные сообщения об ошибках
Когда дело доходит до утверждения результата / состояния, полезно включать необязательное сообщение. Это упрощает работу в случае сбоя теста, особенно при запуске как части процесса сборки или с помощью внешнего инструмента.
Знаки подчеркивания
Последняя (хотя и необязательная) позиция, которой я придерживаюсь, - это использование подчеркивания для имен тестов. Хотя я не поклонник подчеркивания в производственном коде, их использование в именах тестов полезно, поскольку имена тестов часто намного длиннее. Быстрый взгляд на название теста, в котором используются символы подчеркивания, оказывается намного более читаемым, хотя это субъективно и является источником многих споров в отношении практики модульного тестирования.
Интеграционные тесты
К интеграционным тестам применяются те же стандарты, с той лишь разницей, что расположение таких тестов должно быть отделено от модульных тестов. В приведенном выше примере кода тестовый класс будет называться PersonTests и находиться в файле с именем PersonTests.cs . Интеграционные тесты будут называться аналогичным образом - PersonIntegrationTests , расположенный в PersonIntegrationTests.cs . Для этих тестов можно использовать один и тот же проект, но убедитесь, что они находятся в разных каталогах.
Сгруппируйте ваши тесты по установкам, создайте класс теста вокруг этой установки и назовите его с суффиксом Test или IntegrationTest. Используя тестовый фреймворк, например JUnit или TestNG, вы можете называть свои тестовые методы так, как вам хочется. Я бы назвал метод тем, что он тестирует, предложением в верблюжьем регистре, а не префиксом test. Фреймворки используют аннотацию @Test, чтобы пометить метод как тестовый.
Я просто пишу для чего. Не похоже, что вам придется вводить имена где-либо еще, поэтому наличие testWibbleDoesNotThrowAnExceptionIfPassedAFrobulator не проблема. Очевидно, что все, что является тестом, начинается с слова «тест».
Поучительно взглянуть на BDD (поведенческая разработка) и , в частности, на эту запись в блоге .
BDD в основном фокусируется на компонентах и на том, что они должны делать. Следовательно, это напрямую влияет на то, как вы называете / структурируете свои тесты, а также на код, который они используют для настройки условий и проверки. BDD позволяет не только разработчикам читать / писать тесты, но и нетехнические члены команды (бизнес-аналитики и т. Д.) Могут вносить свой вклад, определяя тесты и проверяя их.
Я использую конструкцию FunctionTestCondition . Если бы у меня было два метода, Get и Set , я бы, возможно, создал следующие методы тестирования:
GetTest- положительный тест (все в порядке).GetTestInvalidIndexдля проверки того, что в метод передается недопустимый индекс.GetTestNotInitializedдля проверки, когда данные не вводятся перед использованием.SetTestSetTestInvalidIndexSetTestTooLargeValueSetTestTooLongString