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

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

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

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

10.12.2008 23:06:08
15 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

98
10.12.2008 23:14:56
Если ваш конструктор имеет, например, условие if (условие), вам необходимо проверить оба потока (true, false). Если ваш конструктор выполняет какую-то работу перед установкой. Вы должны проверить, что работа выполнена.
graffic 25.06.2010 09:20:13
Что делать, если у вас есть checkArgumntв конструкторе (может быть, для проверки объекта является нулевым или нет)? Стоит ли это тестировать?
noMAD 4.11.2014 22:31:31
Да, часто стоит тестировать конструкторы с их собственным сложным поведением.
yfeldblum 5.11.2014 22:46:44
Я знаю, что опоздал на эту вечеринку - но, вообще говоря, я не считаю конструкторы хорошим местом для размещения логики или проверок. Вместо этого использование, например, каких-либо валидаторов запросов для ваших операций класса может иметь для меня больше смысла. Хотя мы должны проверить нулевую ссылку в конструкторе, но я не вижу смысла в модульном тестировании, почему? потому что ваша операция должна завершиться неудачей, если этот объект имеет значение null, что имеет смысл, так как «поведение» не выполняется, и мы должны выполнить модульный тест, а не фактические конструкторы
Alix 24.07.2019 09:34:54

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

9
10.12.2008 23:09:37
Правда, я даже не думал об этом. шлепает по лбу
Nathan W 10.12.2008 23:12:16
Не каждый, если в нем несколько конструкторов или несколько потоков управления.
Victor Sergienko 12.08.2010 09:44:05

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

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

41
13.06.2012 10:04:18
Я никогда не вкладывал никакой логики в мои конструкторы. Просто сеттеры.
Nathan W 10.12.2008 23:11:25
@BrianGenisio, спасибо за подсказку, я просто добавил несколько тестов ArgumentNullException и код в свое приложение ... по какой-то причине его никогда не было ...
CaffGeek 15.05.2012 16:37:46

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

1
10.12.2008 23:22:40
100% покрытие - несбыточная мечта, и любой, кто говорит вам по-другому, продает вам новый блестящий инструмент тестирования. ;) Я шучу ... вроде.
Steven Behnke 11.12.2008 01:58:36
Это может быть проблемой на старых системах, но если вы начинаете новый проект с нуля, на мой взгляд, 100% - единственный путь. Я работал на системах со 100% покрытием. Мы тестировали, ездили все.
digiarnie 12.12.2008 05:45:00
ОК, у вас было 100% покрытие. Но вы проверили все пути выполнения? Первое не подразумевает второго.
kdgregory 12.12.2008 13:15:16
Реальные 100% могут быть легко достигнуты с помощью тестов, которые ничего не делают, кроме как заглушают и тестируют на микроуровне. Но 100% охват тестами, которые вы считаете функцией системы. пути обеспечат вам большую уверенность в обслуживании или новой работе, даже если не каждый путь выполнения учтен.
digiarnie 12.12.2008 23:51:34
100% coverage of that you believe to be the system's functional paths.другими словами: не 100%
Max Hodges 30.10.2012 17:52:50

Какое поведение экземпляра SystemInfoзависит от значения wrapper?

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

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

0
10.12.2008 23:31:31

Модульное тестирование - это проверка путей выполнения, что часто называют Cyclomatic Complexity

Если у вас нет пути на выбор, нет, если, нет цикла, нет GOTO (= P), это не очень полезно

-1
10.12.2008 23:37:49
Я не согласен с вами, что тестирование метода без каких-либо ifs / loops / gotos не имеет смысла. Всегда есть хотя бы один путь выполнения, и вы должны проверить его, даже если он единственный.
Adam Byrtek 11.12.2008 00:08:53
Эрик, как насчет тестирования граничных случаев - и тестирования репрезентативных значений между границами. Например, входные значения 0 и 1 могут рассматриваться как граничные случаи для функции квадратного корня, потому что там входные и выходные значения равны. Так что тестируйте, например, -10, -1, -0,5, 0, 0,5, 1 и 10. Или также тестируйте по всему диапазону. Если ваша функция должна работать для входов до 4096, попробуйте 4095 и 4097 ...
Max Hodges 30.10.2012 18:05:05

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

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

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

13
11.12.2008 21:02:03

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

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

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

0
12.12.2008 12:48:52

Если конструктор содержит некоторую логику, такую ​​как инициализация класса, я думаю, вам следует протестировать сам конструктор. Или вы можете поговорить с разработчиком, что размещение инициализации в конструкторе снизит тестируемость тестируемого кода.

0
19.12.2008 10:03:45

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

3
20.02.2010 19:45:46
у вас есть ссылка для требования FDA?
Ryan_S 25.02.2016 22:51:01

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

1
20.02.2010 19:50:05

Это зависит.

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

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

3
20.02.2010 19:53:52

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

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

7
9.02.2012 16:16:19
Это старая угроза, но я полностью согласен, конструктор по умолчанию должен быть протестирован, а другие конструкторы должны быть протестированы, чтобы дать желаемое поведение, когда требуемые аргументы отсутствуют. С Dependency Injection очень возможно, что конструктор по умолчанию может вызвать циклический цикл зависимостей, который вы никогда не увидите, если никогда не будете использовать конструктор по умолчанию.
Etienne Charland 10.02.2019 05:01:27
Все приведенные здесь примеры (за исключением, может быть, замены на одноэлементный, но в этом случае даже не должно быть общедоступного конструктора по умолчанию для тестирования) - это вещи, которые приведут к ошибке компилятора. Нет необходимости просто тестировать конструктор без логики с помощью модульного теста, но это - настоящая трата времени и денег. Если конструктор имеет логику (кроме простой установки свойств), то он должен быть абсолютно протестирован. Также @EtienneCharland конструктор по умолчанию по определению не имеет зависимостей (вообще никаких параметров), поэтому он не может создать циклический цикл зависимостей.
Tyler W 8.11.2019 21:42:25

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

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

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

2
15.10.2013 01:55:59

Я тестирую конструкторы, когда они содержат логику - например, валидацию или условную установку частного состояния. Ошибки валидации в конечном итоге выдают исключение из конструктора. Успешное выполнение заканчивается созданием объекта, который демонстрирует определенное поведение в зависимости от состояния, которое было установлено в конструкторе. В любом случае, это требует тестирования. Но тесты конструктора скучны, потому что все они выглядят одинаково - вызовите конструктор, сделайте утверждение. Объявления методов тестирования часто занимают больше места, чем вся логика тестирования ... Поэтому я написал простую библиотеку тестирования, которая помогает писать декларативные тесты для конструкторов: как легко тестировать логику проверки в конструкторах в 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();

}

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

4
25.09.2018 23:22:30