Тестирует проекты в решении

Question

В .NET вы должны поместить проекты модульного тестирования вместе с остальным решением? Или должно быть тестовое решение, в котором размещены все тестовые проекты?

У нас есть все тестовые проекты с нашим решением на базе кода ... это кажется немного громоздким.

Что ты обычно делаешь?

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

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

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

Answer 7

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