Испытательные проекты в решении

Ответ 1

В нашем текущем проекте мы решили поместить все модульные тесты в отдельные проекты. Код приложения и тесты находятся в одном решении, но по крайней мере мы можем построить (и развернуть) версию без кода unit test.

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

Обычно я помещаю модульные тесты в свои собственные проекты и тесты интеграции в свой собственный проект в рамках прикладного решения.

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

Ответ 6

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

Ответ 7

Посмотрите на дизайн своего проекта. Если он находится где-то рядом с макетом MVC или одним из его альтернатив, вы должны иметь разные уровни разных сборок. Сделайте один тестовый узел для каждого уровня вашего дизайна.

Наш тестовый проект обычно запускается вместо проекта, который создает EXE. Наш проект EXE представляет собой тонкую оболочку, которая передает события и информацию в сборку, заполненную классами контроллеров, которые содержат код, который большинство людей помещает в проект EXE. Это позволяет тестовому проекту притворяться EXE для 90% обычного процесса тестирования.

Мы по-прежнему разрабатываем лучшую схему для реальных тестовых случаев. Сейчас у нас есть несколько основных уровней нашей утилиты инфраструктуры, Applicaiton Objects, UI Framework, Commands, UI Controllers и EXE. У нас есть одна сборка для каждого уровня, кроме EXE (которая проверена вручную). Когда мы редактируем сборку, мы загружаем тестовую сборку для этого уровня. Когда нам нужно делать что-то, что касается каждого уровня, мы должны загрузить все тестовые сборки.

Во время процесса создания одной кнопки мы запускаем тестовый проект exe. (Для этого у нас есть отдельная утилита).