Это важно для модульного тестирования конструктора?

Question

Должен ли я конструкторам модульных тестов? Скажем, у меня есть такой конструктор:

IMapinfoWrapper wrapper;
public SystemInfo(IMapinfoWrapper mapinfoWrapper)
{
    this.wrapper = mapinfoWrapper;
}

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

Answer 1

Модульное тестирование - это проверка открытых состояний, поведения и взаимодействия ваших объектов.

Если вы просто установили приватное поле в конструкторе, что там тестировать?

Не беспокойтесь о юнит-тестировании ваших простых аксессоров и мутаторов. Это просто глупо, и это никому не помогает.

Answer 2

Да. Если в вашем конструкторе есть логика, вы должны проверить ее. Простая установка свойств - это не логика ИМО. Условные выражения, поток управления и т. Д. - логика.

Edit: Вероятно, вам следует проверить, когда IMapinfoWrapper имеет значение null, требуется ли эта зависимость. Если это так, то это логика, и у вас должен быть тест, который перехватывает ваше ArgumentNullException или что-то еще ... ваши тесты - это спецификации, определяющие поведение кода. Если он генерирует ArgumentNullException, то это должно быть указано в тесте.

Answer 3

В: Если вы устанавливаете переменную-член в конструкторе, почему вы ее устанавливаете.

A: Потому что у вас есть неудачный модульный тест, который можно только пройти, установив его в конструкторе.

Если вы используете эту логику, когда вы пишете код только для прохождения модульного теста (Test Driven Development), то у вас уже будет ответ на ваш вопрос.

Answer 4

Нет. Его функциональность будет проверена каждым другим модульным тестом в классе.

Answer 5

Вы обязательно должны проверить конструктор. Если у вас есть конструктор по умолчанию, вы должны проверить, что он может быть вызван. Что, если впоследствии класс будет изменен - ​​возможно, он станет одноэлементным, или конструктор по умолчанию будет удален в пользу одного требующего параметра? В этом случае тест должен провалиться, чтобы предупредить об этом изменении (чтобы класс или тест могли быть исправлены в соответствии с новым требованием).

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

Answer 6

Я тестирую конструкторы, когда они содержат логику - например, проверка или условная установка частного состояния. Ошибки валидации в конечном итоге выдают исключение из конструктора. Успешное выполнение заканчивается созданием объекта, который демонстрирует определенное поведение в зависимости от состояния, которое было установлено в конструкторе. В любом случае, это требует тестирования. Но тесты конструктора скучны, потому что все они выглядят одинаково - вызовите конструктор, сделайте утверждение. Объявления методов тестирования часто занимают больше места, чем вся логика тестирования ... Поэтому я написал простую библиотеку тестирования, которая помогает писать декларативные тесты для конструкторов: Как легко тестировать логику проверки в конструкторах в C #

Вот пример, в котором я пробую семь тестовых примеров на конструкторе одного класса:

[TestMethod]
public void Constructor_FullTest()
{

    IDrawingContext context = new Mock<IDrawingContext>().Object; 

    ConstructorTests<Frame>
        .For(typeof(int), typeof(int), typeof(IDrawingContext))
        .Fail(new object[] { -3, 5, context }, typeof(ArgumentException), "Negative  length")
        .Fail(new object[] { 0, 5, context }, typeof(ArgumentException), "Zero length")
        .Fail(new object[] { 5, -3, context }, typeof(ArgumentException), "Negative width")
        .Fail(new object[] { 5, 0, context }, typeof(ArgumentException), "Zero width")
        .Fail(new object[] { 5, 5, null }, typeof(ArgumentNullException), "Null drawing context")
        .Succeed(new object[] { 1, 1, context }, "Small positive length and width")
        .Succeed(new object[] { 3, 4, context }, "Larger positive length and width")
        .Assert();

}

Таким образом, я могу тестировать все соответствующие случаи для моего конструктора, не набирая много.

Answer 7

Это зависит.

Я бы не стал писать специальный тест конструктора для чего-то такого простого, как пример, который вы привели.

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

Answer 8

Во многих FDA-регулируемых средах более критичный код должен быть проверен на 100% ... включая построение классов. Таким образом, тестирование конструкторов иногда необходимо независимо от того, рассуждают они или нет. Кроме того, компаниям, использующим инструменты статического анализа, необходимо убедиться, что ВСЕ члены данных класса правильно инициализированы, чтобы не было ошибок, хотя код может работать без ошибок и без ошибок. Обычно инициализация членов данных выполняется в конструкторе ... просто пища для размышлений.

Answer 9

Я думаю, что ответ "Да".

Существует множество кода, который ужасно предполагает инициализированное состояние объекта вместо нулевой ссылки - часто, когда в конструкторе не заданы явные значения.

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

Answer 10

Тестирование аксессоров и мутаторов также необходимо, если разработчик не гарантирует, что никакая логика состояния не может быть изменена. Например, если используется шаблон проектирования для Singleton, часто используются методы доступа или свойства, а если класс не инициализирован, это делается из метода доступа, поскольку конструктор является закрытым. В C ++ можно сделать их функции постоянными или статическими, в которых данные членов класса не могут быть изменены. (Примечание: даже использование static немного рискованно, поскольку эти переменные часто бывают глобальными.) Однако без проверки, если кто-то не сможет использовать превентивные меры, как вы можете гарантировать со 100% точностью, что написанное не может превратиться в отказ? время? Техническое обслуживание вряд ли надежно.