Юнит-тестирование именных лучших практик [закрыто]

Нет, такой гарантии нет. Он не определен в соответствии со стандартом C ++.

Bjarne Stroustrup также явно говорит об этом в разделе «Язык программирования C ++», раздел 6.2.2, с некоторыми аргументами:

Better код может быть сгенерирован при отсутствии ограничений на порядок оценки выражения

Хотя это технически относится к более ранней части того же раздела, где говорится, что порядок оценки частей выражения также undefined, т.е.

int x = f(2) + g(3);   // undefined whether f() or g() is called first
509
задан Community 23 May 2017 в 12:18
поделиться

9 ответов

I like Roy Osherove's naming strategy, it's the following:

[UnitOfWork_StateUnderTest_ExpectedBehavior]

It has every information needed on the method name and in a structured manner.

The unit of work can be as small as a single method, a class or as large as multiple classes. It should represent all the things that are to be tested in this test case and are under control.

For assemblies I use the typical .Tests ending, which I think is quite widespread and the same for classes (ending with Tests):

[NameOfTheClassUnderTestTests]

Previously I used Fixture as suffix instead of Tests but I think the latter is more common, then I changed the naming strategy.

491
ответ дан 22 November 2019 в 22:23
поделиться

название тестовый сценарий для класса, Foo должен быть FooTestCase или что-то как он (FooIntegrationTestCase или FooAcceptanceTestCase) - так как это - тестовый сценарий. см. http://xunitpatterns.com/ для некоторых стандартных соглашений о присвоении имен как тест, тестовый сценарий, протестируйте приспособление, метод тестирования, и т.д.

0
ответ дан 23 May 2017 в 12:18
поделиться

Мне нравится этот стиль именования:

OrdersShouldBeCreated();
OrdersWithNoProductsShouldFail();

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

74
ответ дан Sklivvz 23 May 2017 в 12:18
поделиться
  • 1
    Я также столкнулся с рекурсивной проблемой параметров, /controller/action?param=1?param=2?param=3, но request.path, работавший превосходный для меня. – Justus Romijn 12 April 2011 в 08:54

См.: http://googletesting.blogspot.com/2007/02/tott-naming-unit-tests-responsibly.html

Для имен метода тестирования, я лично нахожу использующие подробные и самозарегистрированные имена очень полезными (вместе с комментариями Javadoc, которые далее объясняют, что тест делает).

8
ответ дан Ates Goral 23 May 2017 в 12:18
поделиться

Kent Beck предлагает:

  • Одно тестовое приспособление на 'единицу' (класс Вашей программы). Тестовые приспособления являются самими классами. Тестовое название приспособления должно быть:

    [name of your 'unit']Tests
    
  • Тесты (тестовые методы приспособления) имеют имена как:

    test[feature being tested]
    

, Например, имея следующий класс:

class Person {
    int calculateAge() { ... }

    // other methods and properties
}

тестовое приспособление А было бы:

class PersonTests {

    testAgeCalculationWithNoBirthDate() { ... }

    // or

    testCalculateAge() { ... }
}
49
ответ дан marc_s 23 May 2017 в 12:18
поделиться

В VS + NUnit я обычно создаю папки в своем проекте собрать в группу функциональные испытания. Тогда я создаю классы приспособления модульного теста и называю их в честь типа функциональности, которую я тестирую. [Тест] методы называют вроде Can_add_user_to_domain:

- MyUnitTestProject   
  + FTPServerTests <- Folder
   + UserManagerTests <- Test Fixture Class
     - Can_add_user_to_domain  <- Test methods
     - Can_delete_user_from_domain
     - Can_reset_password
2
ответ дан Kev 23 May 2017 в 12:18
поделиться

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

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

2
ответ дан lesmana 23 May 2017 в 12:18
поделиться

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

Давайте скажем, я тестирую класс Settings в проекте в пространстве имен MyApp.Serialization .

Сначала я создам тестовый проект с MyApp.Serialization.Tests пространство имен.

В рамках этого проекта и, конечно, пространства имен я создам класс с именем IfSettings (сохраненный как IfSettings.cs).

Допустим, я тестирую SaveStrings () метод. -> Я назову тест CanSaveStrings () .

Когда я запустил этот тест, он покажет следующий заголовок:

MyApp.Serialization.Tests.IfSettings.CanSaveStrings

Я думаю, что это очень хорошо говорит мне, что это за тестирование.

Конечно, полезно, что в английском языке существительное «Tests» то же самое, что и глагол «tests».

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

Обычно имена тестов должны начинаться с глагола.

Примеры включают:

  • Обнаруживает (например, DetectsInvalidUserInput)
  • Выбрасывает (например, ThrowsOnNotFound)
  • Будет (например, WillCloseTheDatabaseAfterTheTransaction)

и т. Д.

Другой вариант - использовать «это» вместо «если».

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

[ Редактировать ]

После того, как я использовал вышеупомянутое соглашение об именах немного дольше, я обнаружил, что префикс If может сбивать с толку при работе с интерфейсами. Так уж получилось, что тестовый класс IfSerializer.cs очень похож на интерфейс ISerializer.cs во вкладке «Открытые файлы». Это может сильно раздражать при переключении между тестами, тестируемым классом и его интерфейсом. В результате я бы выбрал That вместо If в качестве префикса.

Кроме того, теперь я использую - только для методов в моих тестовых классах, поскольку это не считается лучшей практикой где-либо еще. - «_» для разделения слов в именах моих тестовых методов, например:

  • [Тест] public void detect_invalid_User_Input () *

Я считаю, что это легче читать.

[ Конец редактирования ]

Я надеюсь, что это породит еще несколько идей, так как я считаю тесты именования очень важными, поскольку они могут сэкономить вам много времени, которое в противном случае было бы потрачено на попытки понять что делают тесты (например, после возобновления проекта после длительного перерыва).

7
ответ дан 22 November 2019 в 22:23
поделиться

Имена классов . Что касается имен тестовых устройств, я считаю, что слово «Test» довольно часто встречается на повсеместном языке многих доменов. Например, в инженерной области: StressTest , а в области косметики: SkinTest . Извините, что не согласен с Кентом, но использование «Test» в моих тестовых таблицах ( StressTestTest ?) Сбивает с толку.

«Единица» также часто используется в доменах. Например, Единица измерения . Является ли класс MeasurementUnitTest тестом «Measurement» или «MeasurementUnit»?

Поэтому я предпочитаю использовать префикс «Qa» для всех моих тестовых классов. Например, QaSkinTest и QaMeasurementUnit . Его никогда не путают с объектами домена, а использование префикса вместо суффикса означает, что все тестовые инструменты визуально работают вместе (полезно, если в вашем тестовом проекте есть подделки или другие классы поддержки)

Пространства имен . Я работаю на C # и храню свои тестовые классы в том же пространстве имен, что и класс, который они тестируют. Это удобнее, чем иметь отдельные тестовые пространства имен. Конечно, тестовые классы находятся в другом проекте.

Имена тестовых методов . Я люблю называть свои методы WhenXXX_ExpectYYY. Он проясняет предварительное условие и помогает с автоматизированной документацией (а-ля TestDox). Это похоже на совет в блоге о тестировании Google, но с большим разделением предварительных условий и ожиданий. Например:

WhenDivisorIsNonZero_ExpectDivisionResult
WhenDivisorIsZero_ExpectError
WhenInventoryIsBelowOrderQty_ExpectBackOrder
WhenInventoryIsAboveOrderQty_ExpectReducedInventory
17
ответ дан 22 November 2019 в 22:23
поделиться
Другие вопросы по тегам:

Похожие вопросы: