Лучшие практики именования модульных тестов [закрыто]

Я люблю "следует" стандарт именования для тесты называя тест приспособление после испытываемого устройства (т. е. класса).

чтобы проиллюстрировать (используя C# и NUnit):

[TestFixture]
public class BankAccountTests
{
  [Test]
  public void Should_Increase_Balance_When_Deposit_Is_Made()
  {
     var bankAccount = new BankAccount();
     bankAccount.Deposit(100);
     Assert.That(bankAccount.Balance, Is.EqualTo(100));
  }
}

почему "следует"?

Я нахожу, что это заставляет тестовых авторов называть тест предложением по строкам " должен [быть в некотором состоянии] [после/До / когда] [действие принимает место]"

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

обновление:

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

обновление (4 года позже...)

для тех, кто заинтересован, мой подход к именованию тестов развивался на протяжении многих лет. Одна из проблем, с должны шаблон, который я описал выше, как его нелегко узнать с первого взгляда, какой метод тестируется. Для ООП я думаю, что имеет смысл начать имя теста с тестируемого метода. Для хорошо спроектированного класса это должно привести к читаемым именам методов тестирования. Теперь я использую формат, подобный <method>_Should<expected>_When<condition>. Очевидно, в зависимости от контекста может хотите заменить глаголы Should/When чем-то более подходящим. Образец: Deposit_ShouldIncreaseBalance_WhenGivenPositiveValue()

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

OrdersShouldBeCreated();
OrdersWithNoProductsShouldFail();

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

Кент Бек предлагает:

• одно приспособление теста в "блок" (класс вашей программы). Тестовые светильники-это сами классы. Название испытательного приспособления должно быть:

  [name of your 'unit']Tests
  

• тестовые случаи (методы приспособления теста) имеют имена как:

  test[feature being tested]
  

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

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

    // other methods and properties
}

тестовая фикстура будет:

class PersonTests {

    testAgeCalculationWithNoBirthDate() { ... }

    // or

    testCalculateAge() { ... }
}

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

"Unit" также используется много в доменах. Е. Г. MeasurementUnit. Класс называется MeasurementUnitTest испытание "измерения " или"MeasurementUnit"?

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

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

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

WhenDivisorIsNonZero_ExpectDivisionResult
WhenDivisorIsZero_ExpectError
WhenInventoryIsBelowOrderQty_ExpectBackOrder
WhenInventoryIsAboveOrderQty_ExpectReducedInventory

посмотреть: http://googletesting.blogspot.com/2007/02/tott-naming-unit-tests-responsibly.html

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

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

допустим, я тестирую настройки класс в проекте в MyApp.Сериализация пространство имен.

сначала я создам тестовый проект с помощью MyApp.Сериализация.Тесты пространство имен.

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

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

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

MyApp.Сериализация.Тесты.IfSettings.CanSaveStrings

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

конечно, полезно, что на английском языке существительное " тесты "совпадает с глаголом"тесты".

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

обычно Testnames придется начинать с глагола.

примеры:

• обнаруживает (например, DetectsInvalidUserInput)
• Броски (например, ThrowsOnNotFound)
• воли (напр. WillCloseTheDatabaseAfterTheTransaction)

etc.

другой вариант-использовать "это "вместо"Если".

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

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

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

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

• [Test] public void detects_invalid_User_Input() *

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

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

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

Я использую Дано-Когда-То концепции. Взгляните на эту короткую статью http://cakebaker.42dh.com/2009/05/28/given-when-then/. Статья описывает это понятие в терминах BDD, но вы можете использовать его и в TDD без каких-либо изменений.

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

в VS + NUnit я обычно создаю папки в своем проекте, чтобы сгруппировать функциональные тесты вместе. Затем я создаю классы приспособлений модульного теста и называю их после типа функциональности, которую я тестирую. Методы [Test] называются по строкам 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

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

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

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