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

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

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

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

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

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

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

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

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

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

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

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

Да. Если у Вас есть логика в Вашем конструкторе, необходимо протестировать ее. Просто установкой свойств не является логический IMO. Условные выражения, поток управления, и т.д. ЯВЛЯЮТСЯ логикой.

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

Q: при установке членской переменной в конструкторе почему Вы устанавливаете ее.

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

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

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

Проверьте https://koding.com , что у него есть Go/PHP/Ruby/Perl/Python/Git/Ftp/SSH, с виртуальной машиной с корневым доступом.

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

Это зависит.

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

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

Переопределение определенных методов ComponentAdapter является удобной альтернативой реализации всех методов ComponentListener .

проверьте https://koding.com , есть ли Go/PHP/Ruby/Perl/Python/Git/Ftp/SSH, с виртуальной машиной с корневым доступом.

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