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

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

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

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

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

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

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

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

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

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

Это зависит.

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

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

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

}

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

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

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

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

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

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

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

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

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

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

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

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

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

модульное тестирование - это проверка путей выполнения, что-то часто упоминается как Цикломатическая Сложность

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