Должны ли модульные тесты быть в их собственном проекте в .Net Solution - PullRequest
18 голосов
/ 12 февраля 2010

Должен ли я начать новый проект для моих модульных тестов? Это будет означать, что я получу два исполняемых файла правильно? Тогда я беспокоюсь об организации пространства имен. Смогу ли я поместить модульный тест в те же пространства имен, что и классы, которые они тестируют, хотя они являются частью другого проекта?

Это поднимает другой вопрос. Я знаю, что соглашение об именах пространства имен - это CompanyName.TechnologyName.Feautre.Design. Как бы я понял это правильно в макете моего решения / проекта? Имя решения = название компании, название проекта = название технологии?

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

Ответы [ 5 ]

34 голосов
/ 12 февраля 2010

Наилучший подход - иметь отдельный проект модульных испытаний для «производственного проекта». Это гарантирует, что вы можете изменять и перемещать их попарно.

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

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

Я называю свои пространства имен, добавляя «UnitTest» после целевого пространства имен.

8 голосов
/ 12 февраля 2010

Я склонен иметь конкретный тестовый проект / сборку на сборку. Тестовая сборка будет иметь то же имя, что и сборка, которую она должна тестировать, с добавлением .Test в имя и пространство имен.

Таким образом, вы сохраняете свои тесты изолированными, и они не развертываются с вашим рабочим кодом.

5 голосов
/ 12 февраля 2010

1 тестовый проект для решения с папками => регрессия / интеграция / модуль, в котором есть подпапки, которые «отражают» архитектуру проекта / папки вашего решения.

Помните - тесты не ваш рабочий код. Они должны быть отделены.

2 голосов
/ 12 февраля 2010

Да. Ваши модульные тесты должны быть отдельным проектом, который компилируется в свою собственную DLL.

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

Что касается именования, мы обычно выбираем «кодовое имя» для каждого проекта - текущий называется «Занзибар» - и затем получаем такие проекты, как:

MyCompany.Zanzibar.Website (веб-приложение ASP.NET MVC)

MyCompany.Zanzibar.Website.Testing (содержит модульные тесты для веб-приложения MVC)

1 голос
/ 12 февраля 2010

Да. Создайте проект модульного тестирования для каждого проекта решения.

Будет только один исполняемый файл. Модульные тесты хранятся в DLL.

Почему бы не добавить 'UnitTests' в соответствующее пространство имен.

...