Написать модульные тесты в сборку или в отдельную сборку?

Question

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

Answer 1

У меня есть одно решение с интерфейсным проектом, тестовым проектом, доменным проектом и проектом данных. Когда я выпускаю, я просто публикую интерфейс, который не ссылается на Tests, поэтому он не компилируется.

Редактировать: Суть в том, что вы не хотите, чтобы это было частью вашего финального релиза. Вы можете достичь этого автоматически в VS, используя отдельный проект / сборку. Однако вы можете иметь его в той же сборке, но тогда просто не компилируйте этот код, если вы используете nant или msbuild. Хотя немного грязно, держите вещи в порядке, используйте отдельную сборку:)

Answer 2

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

Оставление тестового кода в развертывании:

• раздувает код без особого преимущества - все эти дополнительные теги кода, которые вообще не будут использоваться на месте.
• влияет на релизы - выпускаете ли вы новую версию полного приложения. когда то, что вы улучшили, есть только в тестовом коде, например В результате исправления ошибки расширен набор тестов.
• вы не можете легко повторно использовать тестовую среду в другом проекте - если вы всегда выпускаете приложения, забитые тестовым кодом, любые последующие проекты должны повторно использовать один и тот же тестовый код. В противном случае вы заканчиваете с ситуацией, когда приложение A использует v1.2 тестовой платформы для этих аспектов приложения. которые являются общими для всех ваших приложений, например, уровень представления или структура бизнес-логики и т. д. И приложение. B использует v1.1 тестовой среды, приложение. C использует v1.2.1 и т. Д.

Развязка с другой стороны позволяет:

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

НТН

ура

Rob

Answer 3

Это широко обсуждается во всей сети.

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

Answer 4

в другой сборке. В противном случае ваша сборка будет ссылаться на тестовый фреймворк (например, Nunit.Framework.dll), и вам нужно будет установить его на клиентском компьютере,

Даже если то, что вы отправляете, является библиотекой, и вы хотите, чтобы ваш клиент рассматривал модульные тесты в качестве примера или конкретное указание на то, как использовать предоставленные вами объекты, преимущество в том, что они включены в производственную сборку, очень мало. 1003 *

Answer 5

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