Какие популярные соглашения об именах для модульных тестов?

Пока вы следуете единственной практике, это не имеет значения. Как правило, я пишу единый модульный тест для метода, который охватывает все варианты метода (у меня есть простые методы;), а затем пишу более сложные наборы тестов для методов, которые в этом нуждаются. Таким образом, моя структура именования обычно является тестовой (пережиток JUnit 3).

Первый набор имен для меня более читабелен, поскольку CamelCasing разделяет слова, а нижние полосы - отдельные части схемы именования.

Я также стараюсь включать "Test" где-нибудь, либо в имя функции, либо в окружающее пространство имен или класс.

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

• Ясно, что такое каждое тестовое состояние.
• Конкретно об ожидаемом поведении.

Что еще нужно от имени теста?

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

Что до длины и использования подчеркивания, его тестовый код, кого это, черт возьми, волнует? Только вы и ваша команда увидите его, если он читабельный и ясно показывает, что делает тест, продолжайте! :)

Тем не менее, я все еще новичок в тестировании и веду блог о моих приключениях с ним :)

Я называю свои методы тестирования, как и другие методы, с использованием «PascalCasing» без каких-либо подчеркиваний или разделителей. Я оставляю постфикс Тест для метода, потому что он не добавляет значения. То, что метод является тестовым, указывается атрибутом Метод испытания.

[TestMethod]
public void CanCountAllItems() {
  // Test the total count of items in collection.
}

В связи с тем, что каждый тестовый класс должен тестировать только один другой класс, я оставляю имя класса вне имени метода. Имя класса, содержащего тестовые методы, называется так же, как тестируемый класс, с постфиксом «Тесты».

[TestClass]
public class SuperCollectionTests(){
    // Any test methods that test the class SuperCollection
}

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

[TestMethod]
[ExpectedException(typeOf(ArgumentException))]
public void CannotAddSameObjectAgain() {
  // Cannot add the same object again to the collection.
}

Мое соглашение по именованию основано на статье «Советы TDD: правила и рекомендации по именованию тестов» Брайана Кука. Я нашел эту статью очень полезной.

Я использую префикс «T» для тестовых пространств имен, классов и методов.

Я стараюсь быть аккуратным и создаю папки, которые реплицируют пространства имен, затем создаю папку тестов или отдельный проект для тестов и реплицирую производственную структуру для базовых тестов:

AProj
   Objects
      AnObj
         AProp
   Misc
      Functions
         AFunc
   Tests
      TObjects
         TAnObj
            TAnObjsAreEqualUnderCondition
      TMisc
         TFunctions
            TFuncBehavesUnderCondition

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

Это похоже на соглашение об именах интерфейсов (я имею в виду, вы не запутаетесь с вещами, начинающимися с «I», и не с «T»).

Легко просто скомпилировать с тестами или без них.

В любом случае это хорошо в теории и неплохо работает для небольших проектов.

Это также стоит прочитать: Структурирование модульных тестов

The structure has a test class per class being tested. That’s not so unusual. But what was unusual to me was that he had a nested class for each method being tested.

например

using Xunit;

public class TitleizerFacts
{
    public class TheTitleizerMethod
    {
        [Fact]
        public void NullName_ReturnsDefaultTitle()
        {
            // Test code
        }

        [Fact]
        public void Name_AppendsTitle()
        {
            // Test code
        }
    }

    public class TheKnightifyMethod
    {
        [Fact]
        public void NullName_ReturnsDefaultTitle()
        {
            // Test code
        }

        [Fact]
        public void MaleNames_AppendsSir()
        {
            // Test code
        }

        [Fact]
        public void FemaleNames_AppendsDame()
        {
            // Test code
        }
    }
}

И вот почему:

Well for one thing, it’s a nice way to keep tests organized. All the tests (or facts) for a method are grouped together. For example, if you use the CTRL+M, CTRL+O shortcut to collapse method bodies, you can easily scan your tests and read them like a spec for your code.

Мне тоже нравится такой подход:

MethodName_StateUnderTest_ExpectedBehavior

Так что, возможно, приспособьтесь к:

StateUnderTest_ExpectedBehavior

Потому что каждый тест уже будет во вложенном классе

Я обычно использую соглашение MethodName_DoesWhat_WhenTheseConditions, например:

Sum_ThrowsException_WhenNegativeNumberAs1stParam

Однако я часто вижу, что имя теста должно соответствовать структуре модульного тестирования

• Договариваться
• действовать
• Утверждать

Что также следует синтаксису BDD / Gherkin:

• Данный
• Когда
• потом

что означало бы назвать тест следующим образом: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

так что к вашему примеру:

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

Однако я предпочитаю сначала указывать имя тестируемого метода, потому что тогда тесты могут быть расположены в алфавитном порядке или отображаться в алфавитном порядке в раскрывающемся списке элементов в VisStudio, и все тесты для 1 метода сгруппированы вместе.

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

Другими словами, мне нравится: Sum_ThrowsException_WhenNegativeNumberAs1stParam лучше, чем Sum_Throws_Exception_When_Negative_Number_As_1st_Param.