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

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

Структура имеет тестовый класс для каждого тестируемого класса. Это не так уж необычно. Но необычным для меня было то, что у него был вложенный класс для каждого тестируемого метода.

e.g.

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
        }
    }
}

И вот почему:

Ну, во-первых, это хороший способ организовать тесты. Все тесты (или факты) для метода сгруппированы вместе. Например, если вы используете сочетание клавиш CTRL+M, CTRL+O, чтобы свернуть тела методов, вы можете легко просмотреть свои тесты и прочитать их как спецификацию своего кода.

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

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.

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

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

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

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

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

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

Мое соглашение об именах основано на статье "Советы TDD: соглашения об именах тестов" & Руководства" Брайана Кука. Я нашел эту статью очень полезной.

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

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

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

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

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

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

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

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

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

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